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

[irc at mansr.com]

[03:14:57] <kierank_> http://www.youtube.com/watch?v=ZRM6-PrOfZE
[03:14:59] <kierank_> j-b: .....
[04:59:30] <saintdev> gsachin: pong
[07:38:10] <zuxy> hi, do git.ffmpeg.org and git.videolan.org pull from each other?
[07:38:30] <Sean_McG> ummm, no
[07:42:58] <zuxy> Sean_McG: so all the git.ffmpeg.org commits seen from http://git.videolan.org/?p=ffmpeg.git;a=summary were hand picked by Michael?
[07:44:53] <peloverde> by whoever is in the committer field
[07:52:18] <saintdev> boiled_sugar: http://danbooru.donmai.us/post/show/851086
[07:52:37] <boiled_sugar> I think wrong channel
[07:52:42] <saintdev> lol
[07:56:36] <Sean_McG> hahahah
[07:56:56] <Sean_McG> very cute though ^^;
[09:20:02] <ubitux> http://www.osnews.com/story/24401/_lt_strike_gt_Patent_Troll_lt_strike_gt_MPEG-LA_Opens_Attack_on_VP8_WebM
[09:40:29] <_av500_> its actually helping vp8
[09:40:37] <peloverde> not really surprising and not really that trolly considering that parts of vp8 look like they were based on h.264
[09:41:08] <_av500_> peloverde: explain that to the freetards :)
[09:45:52] <peloverde> And I've said this before too, perhaps a better use of that $106 million would have been lobbying to change the us patent system
[10:14:12] <Dark_Shikari> 21:13 <@Dark_Shikari> how did you install yasm?
[10:14:12] <Dark_Shikari> 21:13 < MakePath> yes !
[10:14:56] <peloverde> I'm pretty sure that just loop prints !\n
[10:15:04] <Sean_McG> lol
[10:15:39] <Dark_Shikari> yup.
[10:15:47] <elenril> lol
[10:16:02] <Sean_McG> are there any instructions for where I should start looking when a fate test is failing? as in, for example, where to set my 1st breakpoint in gdb?
[10:17:28] <peloverde> it depends on the test and the type of failure
[10:17:46] <Sean_McG> hrm... this isn't a crash, it's a checksum difference on the test result
[10:18:18] <peloverde> does it work with --disable-asm?
[10:18:28] <Sean_McG> lemme try that
[10:19:19] <peloverde> if it does, from there you can start trying to narrow down which chunk of asm makes it fail
[10:30:43] <Sean_McG> hmmm yeah, succeeds with disable-asm
[10:31:46] <Sean_McG> anyways I should get some rest, I'll look at this again after some shuteye
[11:30:40] <VFR_maniac> libavformat cannot handle aac in mp4+mov-chimera :(
[12:20:30] <Kovensky> bcoudurier: ^
[12:29:10] <merbanan> VFR_maniac: file a bugreport on the roundup tracker
[12:29:34] <VFR_maniac> i figured out the bug
[12:31:05] <VFR_maniac> http://vfrmaniac.fushizen.eu/OtherStuff/0001-Fix-parsing-mp4-with-sound-description-version-0.patch
[13:08:44] <j-b> 'moroning
[13:18:19] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * rcd6a5a57b8 ffmpeg/Makefile:
[13:18:19] <CIA-38> ffmpeg: Add lavfi-showfiltfmts and graph2dot to $(TOOLS)
[13:18:19] <CIA-38> ffmpeg: Allow make clean to remove the corresponding binaries.
[13:18:19] <CIA-38> ffmpeg: Fix issue 2162.
[13:18:19] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:18:28] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r40321376d8 ffmpeg/Makefile:
[13:18:28] <CIA-38> ffmpeg: Allow "make clean" to clean files in tools
[13:18:28] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:18:31] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * re063f5886b ffmpeg/doc/faq.texi: (log message trimmed)
[13:18:31] <CIA-38> ffmpeg: Fix script command in a FAQ entry
[13:18:31] <CIA-38> ffmpeg: In the FAQ section "How do I encode single pictures into movies?", use
[13:18:31] <CIA-38> ffmpeg: -s for generating symbolic links with the ln command.
[13:18:31] <CIA-38> ffmpeg: The script was generating hard links, which is not likely what it was
[13:18:32] <CIA-38> ffmpeg: supposed to do.
[13:18:32] <CIA-38> ffmpeg: Fix issue 2488.
[14:08:42] <Dark_Shikari> pengvado: nice FFT patch.
[15:10:24] * mru curses libavformat
[15:10:40] <kshishkov> memcopy it!
[15:11:17] <pJok> ncurses?
[15:11:27] <mru> any curses will do
[15:11:29] <mru> I'm not particular
[15:12:52] <kshishkov> byt memcpy() if your favourite curse
[15:12:55] <kshishkov> *but
[15:48:53] <CIA-38> ffmpeg: Vitor Sessak <vitor1001 at gmail.com> master * r47d62c965b ffmpeg/libavcodec/bink.c:
[15:48:54] <CIA-38> ffmpeg: Make tables generation insensitive to floating-point implementation
[15:48:54] <CIA-38> ffmpeg: Using doubles make the double -> int cast well defined for all the values
[15:48:54] <CIA-38> ffmpeg: used, with the exception of when s[i]==1.0, which is special-cased.
[15:48:54] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:24:44] <mru> ok, this is scary
[16:25:06] <mru> I made -strict 1 -vsync 0 default and ran fate
[16:25:39] <kshishkov> and got hello from VBV?
[16:25:48] <mru> no
[16:25:57] <mru> just no duplicating or dropping of frames
[16:26:10] <mru> some of the refs have tons of duplicated frames
[16:27:07] <mru> rv30 and rv40 drop about half of the rames
[16:27:10] <mru> +f
[16:27:32] <mru> one mpeg test and one wmv test duplicate a bunch of frames at the start
[16:27:37] <kshishkov> yes, rv30 and rv40 should be dropped completely instead
[16:28:17] <kshishkov> along with their creator
[16:28:24] <mru> you?
[16:28:31] <kshishkov> Buffering Inc
[16:28:37] <mru> many game formats duplicate _every_ frame
[16:28:39] <mru> or more
[16:29:03] <mru> -strict 1 only affect h264 actually
[16:29:30] <mru> but setting that and leaving -vsync at default makes ffmpeg.c drop the 15 first frames on many h264 tests
[16:29:39] * kshishkov believes that RV3/4 and RALF design principle was "every coding is effective if you have lots of Huffman tables for every context"
[16:30:03] <mru> when in doubt, huff
[16:31:14] <kierank> kshishkov: implies there was a design principle
[16:31:42] <kshishkov> mru: context-dependant Huff
[16:32:03] <kshishkov> kierank: of course, how else they could come with "Buffering" message
[16:32:35] <kshishkov> there are hundreds of tables for RALF and even tables for RV3/4 would make RAM cry
[16:33:05] <kierank> kshishkov: what about dts
[16:33:29] <kshishkov> no comment
[17:05:22] <divVerent> ubitux: "MPEG (so not the MPEG-LA) has announced its intent to develop a new video compression standard for the web which will be royalty-free. "The new standard is intended to achieve substantially better compression performance than that offered by MPEG-2 and possibly comparable to that offered by the AVC Baseline Profile."
[17:05:25] <divVerent> sounds VERY promising
[17:05:43] <divVerent> so they say "it sure exceeds MPEG-2, and will be somewhat below AVC Baseline"
[17:05:54] <ubitux> it would be great :)
[17:05:57] <divVerent> when Dark_Shikari is done with it... it'll be somewhere between AVC Baseline and Main
[17:06:01] <divVerent> so, great :P
[17:06:58] <divVerent> as I suppose their estimates are referring to somewhat "ok-ish" reference encoders, and not excessively tuned ones
[17:07:03] <kierank> divVerent: it's like vc-1 all over again
[17:07:21] <divVerent> my point is just... such a thing will likely kill VP8
[17:07:27] <Kovensky> Vitor1001: did you meet another brazilian named Will Almeida in france
[17:07:29] <kierank> vc-1 was meant to be royalty free
[17:07:31] <divVerent> as VP8 simply lacks a good spec
[17:08:00] <mru> they could be planning on making a subset of h264 royalty-free
[17:08:12] <divVerent> doesn't sound like it
[17:08:15] <divVerent> but would be better
[17:08:25] <mru> that would be substantially better than mpeg2 and not quite as good as h264
[17:08:26] <divVerent> h264 baseline + "trivialities" would be a really great codec, for example
[17:08:28] <kierank> iirc baseline was meant to be royalty free at some point
[17:09:20] <kierank> anyway it'll be funny if xiph get involved in mpeg
[17:10:14] <divVerent> I mean... baseline removes 8x8dct (triviality), bframes (triviality), cabac (nontrivial), --cqm flat (just a bunch of numbers, so, triviality), and --weightp 0 (weighted prediction of P-frames again sounds like your typical patent claim)
[17:10:29] <divVerent> basically, H.264 baseline + b-frames would be VERY promising :P
[17:11:22] <divVerent> patenting a set of matrices sounds like abuse of the patent system, so I suppose that must be free
[17:11:48] <divVerent> and size isn't an algorithmic ingenuity, if anyhting, the DCT itself is (but that is too old)
[17:11:53] <kierank> it removes delta_qp
[17:12:03] <kierank> oh baseline
[17:12:07] <kierank> i thought you mean patents
[17:12:15] <divVerent> this was just daydreaming
[17:12:30] <divVerent> about "what can we safely add to H.264, assuming H.264 baseline were royalty free"
[17:12:57] <divVerent> or rather, "if baseline were free, which differences to high can we immediately add back"
[17:13:13] <divVerent> bframes e.g. are very likely not patentable
[17:13:45] <divVerent> 8x8dct POSSIBLY can be, as it also involves an adaptive DCT size decision
[17:14:04] <mru> b-frames were in mpeg1
[17:14:11] <divVerent> mru: exactly
[17:14:16] <divVerent> not used much
[17:14:22] <divVerent> but b-frames aren't exactly a new idea
[17:14:30] <mru> at least as old as mpeg1...
[17:14:36] <mru> which is >20 years
[17:14:46] <divVerent> at least, b-frames are a non trivial idea
[17:15:01] <divVerent> as e.g. "decode order isn't playback order" WAS something new at the time
[17:15:50] <divVerent> basically, B-frames can be summarized as "Assume we remove the requirement that decode order is playback order... what can we gain?"
[17:16:17] <mru> and then h264 goes crazy with lots of ref frames
[17:16:27] <divVerent> yes, but doesn't baseline already do that?
[17:16:39] <mru> don't remember
[17:16:44] <mru> there's probably some restriction
[17:16:49] <divVerent> weighted prediction for p-frames is off, though, in baseline
[17:17:03] <divVerent> but shouldn't this still allow --refs?
[17:17:42] <divVerent> IIRC (not sure), you still can select a different reference frame per macroblock, and maybe even take the arithmetic mean of two or three, without "weighting"
[17:18:29] <kierank> isn't motion vector prediction patented
[17:18:53] <divVerent> doesn't mpeg-1 do that?
[17:20:28] <mru> yes it does
[17:20:42] <divVerent> but basically, I think there is one codec alternative that MAY have a future too
[17:20:47] <divVerent> I call it "VP8x"
[17:21:01] <divVerent> VP8, incompatibly extended by some other interesting features, and properly specified and bugfixed
[17:21:19] <kshishkov> i.e. VP9
[17:21:26] <divVerent> or that
[17:21:32] <divVerent> wouldn't it only be VP9 if On2 makes it, though?
[17:22:00] <kshishkov> VPy then
[17:22:03] <divVerent> hehe
[17:56:21] <Vitor1001> Kovensky: Will Almeida? No. Funny, not a very brazilian name...
[17:56:39] <Kovensky> Vitor1001: lol
[17:57:14] <Kovensky> Vitor1001: he's one of my professors, he came back recentlish from a doctorate in france, don't remember if in 2009 or early 2010
[17:59:29] <Vitor1001> Funny, doctorate in what?
[17:59:53] <Vitor1001> It would surprise me that I don't know a brazilian phd student in physics living in france...
[18:06:38] <Kovensky> Vitor1001: hm, it was something on data processing, not physics
[18:34:08] <Sean_McG> mru: lavf-pixfmt on gcc 4.6 seems to be problematic asm somewhere -- it succeeds when built with disable-asm
[18:34:27] <mru> Sean_McG: next step is to narrow it down
[18:34:38] <Sean_McG> I'm not sure where to start, I'm so new to this
[18:37:39] <Sean_McG> is there a good place to put my 1st breakpoint in gdb, so I can skip all the irrelevant stuff?
[18:37:54] <mru> I wouldn't start chasing this with breakpoints
[18:38:06] <Sean_McG> what I almost need is a unit tester
[18:38:15] <kshishkov> brains
[18:39:47] <kshishkov> 1) look at the diff, determine which files differ
[18:39:50] <mru> Sean_McG: I'd start by looking at the rgb24ToY and rgb24ToUV functions in swscale
[18:40:25] <Sean_McG> wow, I was like, totally looking only in avformat
[18:40:38] <mru> no asm there
[18:40:58] <Sean_McG> except for get_bits.h -- which is another thing that has only started whining since 4.6
[18:42:21] * mru builds gcc 4.6
[18:42:35] <mru> Sean_McG: how about a race?
[18:42:44] <spaam> do it!
[18:42:49] <Sean_McG> I'd lose :)
[18:42:52] <kierank> the troll vs the Sean_McG
[18:43:05] <Sean_McG> I'm not known for being fast
[18:43:08] <kshishkov> meetpoint is in the middle of Atlantic ocean
[18:43:24] <ohsix> you're known for being slow?
[18:43:35] <Sean_McG> pretty much
[18:43:41] <mru> are you accurate?
[18:43:48] <mru> that's what matters here
[18:43:51] <Sean_McG> depends what context
[18:44:35] <mru> the trick is to quickly narrow down the code of interest to a few functions or a file
[18:44:46] <mru> then look for commonly miscompiled patterns there
[18:45:19] <spaam> Sean_McG: you know.. mru built his system with --omg-optimized -O1337
[18:45:29] * Sean_McG snickers
[18:45:51] <mru> CFLAGS="-O3 -march=core2 -fno-tree-vectorize -fomit-frame-pointer -pipe"
[18:45:54] <mru> if you must know
[18:45:55] <kshishkov> spaam: nope, just gcc -mru is enough
[18:46:00] <Sean_McG> vomit frame pointer!
[18:46:38] <spaam> kshishkov: true.
[18:47:00] <Sean_McG> so have any of you bought a Sandy Bridge yet, or waiting for Bulldozer?
[18:47:22] <spaam> buldozer? is that the amd thing?
[18:47:25] <Sean_McG> aye
[18:47:31] <kierank> i'm more of a combine harvester man myself
[18:47:34] <mru> still on a good ol' i7 here
[18:47:48] <Sean_McG> better than mine... C2D 2.4 (MacBook Pro)
[18:48:11] <kierank> http://www.youtube.com/watch?v=tb63PdPweDc
[18:49:06] <Sean_McG> hahahahah
[18:49:09] * kshishkov wants proper 64-bit ARMv11 SoC with 8G RAM and 128G flash
[18:50:13] <spaam> kshishkov: buy one
[18:51:12] <kshishkov> spaam: when it's released as OMAP8 on HamsterBoard I'll buy it
[18:51:43] <Sean_McG> hahahah..."have to go ooh-waah ooh-waah after the first line!"
[18:57:42] <Sean_McG> what does MANGLE() do?
[18:57:54] <mru> it mangles
[18:58:08] <kshishkov> symbol names
[18:58:11] <mru> it prefixes its argument with _ if needed
[18:58:15] <Sean_McG> ah
[19:08:25] <mru> http://pastie.org/1556851
[19:08:58] <Sean_McG> ahhh...wow you are fast
[19:09:32] <mru> it's easy when you know what you're looking for
[19:12:32] <spaam> Sean_McG: you knw.. mru like x86 asm.. so it goes fast to find the problem :)
[19:13:04] <ohsix> theres lots to say about x86, i'd probably be insulted
[19:13:47] <Sean_McG> truthfully I'm not very good at asm, we only touched on it very briefly in college. mostly we were doing C,C++ & Java
[19:14:15] <kshishkov> i.e. not C
[19:14:18] <Sean_McG> and if I was to pick an architecture I liked the most I'd have to say POWER/PPC
[19:14:55] <j-b> BBB: ping
[19:15:57] <BBB> j-b: pong
[19:57:36] <_av500_> BBB: got *it*?
[19:57:57] <BBB> working on "it" :-p actually
[19:58:28] <BBB> but I don't think the code is right, I've been playing with it for a while and I can't get and working results from it :(
[19:58:29] <kshishkov> BBB: BTW, I think we should rewrite RM demuxer from scratch
[19:58:40] <BBB> kshishkov: bcoudurier did that also
[19:58:42] <BBB> check his ffmbc code
[19:58:47] <kshishkov> BBB: iKnow
[19:58:51] <mru> kshishkov: you're volunteered
[19:58:52] <Compn> 'we should'
[19:58:53] <Compn> hehe
[19:59:04] <kshishkov> I think I even tried to port some bits from it
[19:59:26] <kshishkov> mru: I'd like to but I don't want my name name associated with Real formats
[20:00:19] <kshishkov> Compn: in that case "we" is equal to Bonald B. Bultje
[20:01:04] <BBB> never heard of that
[20:01:06] <elenril> BBB must merge the rest of -mt first
[20:01:22] <kshishkov> I agree
[20:01:38] <kshishkov> BBB: doesn't BBB stand for your initials?
[20:01:43] <BBB> no
[20:01:52] <BBB> astrange: ping for rest of ffmpeg-mt :-p
[20:08:34] <Compn> kshishkov : werent the rm specs part of those specs online ? or just rv8/9 specs? :\
[20:09:25] <kshishkov> Compn: I got them in other way
[20:13:21] <Compn> were they as braindead as you always knew ? :)
[20:14:03] <_av500_> i think the accident specs were only rv8 and 9
[20:14:26] <Sean_McG> mru: why were a set of brackets all that was needed to fix that issue? something AT&T syntax?
[20:14:29] <kshishkov> for the rest you need to sacrifice newborns
[20:14:32] <Compn> a format that had 10+ years of hacks added onto it
[20:14:36] <mru> Sean_McG: read more carefully
[20:15:40] <Sean_McG> and a memory constraint became a register constraint?
[20:17:05] <mru> the final code changes from something like "movq 24+ff_bgrfoo, %mm6" to "movq 24(%eax), %mm6", give or take
[20:17:54] <mru> replacing an immediate address with an indexed register
[20:19:00] <Sean_McG> so what change in 4.6 forced that... something in IRA?
[20:19:26] <mru> no clue
[20:19:35] <mru> I was just guessing and got lucky
[20:19:44] <Sean_McG> k
[20:20:03] <mru> although there's a warning related to that:
[20:20:11] <mru> libswscale/swscale_template.c:1885:5: warning: use of memory input without lvalue in asm operand 4 is deprecated [enabled by default]
[20:21:59] <Sean_McG> ...and so there is.
[20:31:03] <mru> BBB: arithmetic fail :)
[20:31:16] <BBB> fuck :-p
[20:31:30] <BBB> ohwell
[20:31:36] <BBB> at least I'm proud to be a fool :-p
[20:32:29] <BBB> the function is kind of odd
[20:32:36] <kshishkov> BBB: tell that to your child in twelve years
[20:32:49] <mru> shifting elements in an array? what's odd about that?
[20:33:00] <Sean_McG> kshishkov: kid won't figure it out themself?
[20:33:04] <BBB> why does it do [srcq+offsetq+...*0/1/2/3] if it could just do [srcq+....*0/1/2/3]?
[20:33:33] <BBB> maybe because he doesn't have to increment srcq in the loop now?
[20:33:38] <BBB> I wonder if that's faster though
[20:33:48] <BBB> srcq+offsetq+.. is bigger binary code than srcq+.., right?
[20:33:58] <mru> no idea
[20:34:16] <mru> mmsize is a constant of course
[20:34:17] <BBB> ruggles: ^^ ?
[20:34:28] <BBB> yeah, mmsize is the constant offset
[20:40:47] <ruggles> BBB: i don't quite understand the question. what alternative are you suggesting?
[20:41:32] <mru> ruggles: update srcq with each iteration and drop offsetq from the []
[20:41:53] <mru> so it would say "mova m1, [srcq+mmsize*n]"
[20:42:16] <mru> that would cost one extra instruction in the loop
[20:42:24] <mru> but the mova opcodes might get smaller
[20:42:38] <ruggles> yes. it just has extra adds. but it's worth a try.
[20:42:46] * mru hugs post-increment addressing
[20:43:05] <kshishkov> r3!
[20:43:12] <mru> the address generation itself should be the same speed
[20:43:25] <mru> but smaller opcodes might be beneficial
[20:43:33] <BBB> ruggles: also, I'm not quite sure why you sub 4*mmsize from offsetq before the loop
[20:43:44] <mru> BBB: he's working backwards
[20:43:50] <ruggles> yes
[20:43:51] <BBB> ruggles: you can just change your absolute offset to be -[4321]*mmsize
[20:43:58] <BBB> instead of [0123]*mmsize
[20:44:25] <BBB> (and of course if you increment offsetq in the loop, you don't have to go backwards anymore)
[20:44:56] <ruggles> sure, i'll test it
[20:45:04] <BBB> ruggles: if you try a few approaches you'll see which is fastest, and whichever is fastest is fine and can be committed (just maybe change cmp x, 0 to test x, x)
[20:46:06] <ruggles> i did try that and it was slower
[20:46:16] <mru> wtf
[20:46:41] <ruggles> yep. i saw gcc likes to do that so i tried it.
[20:46:54] <mru> oh, if gcc does it you probably shouldn't
[20:46:59] <ruggles> :)
[20:47:14] <mru> that's why we write asm, no?
[20:47:26] <BBB> it was slower?
[20:47:27] <BBB> wtf :)
[20:47:34] <BBB> probably alignment-based
[20:47:37] <BBB> ok, nevermind then
[20:47:57] <BBB> asembly is like black magic
[20:47:59] <ohsix> how come the whole thing isn't in assembly
[20:48:00] <BBB> don't try to get it
[20:48:02] <BBB> it'll eat you alive
[20:48:18] <mru> arm asm isn't nearly as dark
[20:48:30] <ohsix> (i know the answer, but gcc still gets a lot of shit for doing  most of the job sort of well)
[20:48:58] <mru> ohsix: gcc does a reasonably good job often enough that it's not worthwhile writing most functions in asm
[20:49:07] <mru> only the most cpu-intensive ones
[20:49:11] <BBB> arm doesn't have 1000 reincarnations of different-but-similar instruction sets that are not 100% compatible, plus 1000000s of revisions of cpus, each of which behaves slightly different with each instruction set
[20:49:12] <ruggles> yeah, i'm inclined to settle for 85% faster than C instead of getting really frustrated trying to get 90% faster than C.
[20:49:15] <ohsix> i know
[20:49:47] <mru> ruggles: you're too modest
[20:49:56] <mru> I don't settle for less than 4x speed of C
[20:50:02] <mru> for simd
[20:50:29] <mru> for non-simd the gain can be anywhere from 30% and up
[20:50:34] <mru> often 100-200%
[20:50:52] <mru> when registers run low
[20:51:17] <BBB> gotta love x86-64
[20:51:20] <BBB> never too few registers
[20:51:21] <BBB> \o/
[20:51:26] <mru> only 16
[20:51:34] <BBB> and if you do, you can use mm and xmm ones as backups
[20:51:35] <ohsix> 649k is enough for everyone
[20:51:41] <BBB> as alternative to stack
[20:51:43] <Sean_McG> heh, and most other architectures had insane register files
[20:51:56] <mru> 16 is quite common
[20:52:02] <mru> some have 32
[20:52:06] <ruggles> 4x speed is same as 75% faster, no?
[20:52:07] <mru> a few have 64
[20:52:11] <ohsix> Sean_McG: they also had weird rules due to the instruction size/format
[20:52:21] <mru> 4x speed is 300% faster
[20:52:39] <mru> did you mean 10% time?
[20:52:40] <ruggles> you can't have 100% faster. that's instantaneous.
[20:52:47] <mru> wrong
[20:52:47] <BBB> mru: don't forget with pextrq, you can use 16 xmm registers for 32 quadwords, saving you up to 256 bytes of stack
[20:52:58] <BBB> ruggles: depends how you count
[20:52:58] <mru> ruggles: 10% time == 900% faster
[20:53:14] <mru> I count in whichever way give the highest numbers
[20:53:15] <Sean_McG> I'd like to learn asm, but I can't find any courses at my local educational institutions
[20:53:16] <ruggles> well if you compare backwards i guess
[20:53:23] <mru> ruggles: do you compare speed or time?
[20:53:36] <mru> 10% less time != 10% faster
[20:53:48] <ohsix> Sean_McG: get anything with an arm in it
[20:53:54] <mru> Sean_McG: there are no good asm courses
[20:54:02] <mru> learn by doing
[20:54:07] <ohsix> things can be had for 20$, make it blink lights
[20:54:14] <Sean_McG> ohsix: I've kinda waffled with doing that, something like a cheap SheevaPlug or what not
[20:54:25] <mru> beagle is a better choice
[20:54:30] <Sean_McG> or a beag...yeah
[20:54:32] <mru> ~$130
[20:54:39] <ohsix> cheap stuff that fits in a breadboard or has useful outputs is better
[20:54:50] <mru> ohsix: depends on what you're after
[20:55:02] <ohsix> blinking lights
[20:55:13] <mru> I can do that with a handful of transistors
[20:55:34] <ruggles> mru: guess my mind is stuck on compression comparisons... too much lossless :)
[20:55:36] <ohsix> who can't, you can actually do it with one
[20:55:43] <Sean_McG> is ARM a good platform to learn asm on?
[20:55:46] <mru> for more elaborate effects, move up to counters, shift registers, and logic gates
[20:55:50] <mru> Sean_McG: sure
[20:55:53] <mru> it's a nice instruction set
[20:55:59] <ohsix> Sean_McG: it wont kill you
[20:56:14] <mru> I wonder if I've used all instructions yet
[20:57:03] <Sean_McG> hmmm, beagleboard xM is $149
[20:57:28] <mru> it's the big brother of the beagle classic
[20:58:06] <ohsix> i already have all the junk, so if i was buying it for something it'd def be the breadboard variety
[20:58:08] <mru> and then there's their cousin the panda at 179
[20:58:42] <mru> 1GHz dual-core goodness
[20:58:45] <ohsix> bringing linux or anything up and poking at it would be dreadfully boring
[20:59:07] <mru> board bringup has its charm
[21:05:01] <peloverde> when i first heard of the panda i assumed it was some chinese version of the beagle
[21:06:23] <mru> there is an indian version of the beagle
[21:06:26] <mru> the devkit800000000000000000
[21:06:34] <Sean_McG> lol
[21:06:38] <mru> perhaps slightly fewer zeros
[21:16:42] <mru> omg libjpeg is convoluted
[21:17:02] <ohsix> it's also largely from the 80s isn't it?
[21:17:13] <mru> all the more reason to keep it small
[21:17:28] <mru> the ffmpeg jpeg decoder is like 5 lines
[21:17:29] <ohsix> and has stuff in it from when you couldn't even fit stuff into memory
[21:17:45] <mru> I'm not talking about the memory management
[21:18:33] <lu_zero> mru: what are you doing with libjpeg?
[21:18:45] <mru> making money
[21:19:39] <pJok> mru, selling libjpeg to the chinese as classified secrets?
[21:19:58] <ohsix> i'm not really talking about memory management either; it jus permeates the whole thing & how its structured
[21:20:00] <lu_zero> mru: if it involves making libjpeg flying on arm I'll use it as well
[21:20:03] <mru> no, taking android's copy of it, making it faster, and selling it back
[21:20:11] <lu_zero> (and plant on gentoo as soon as possible)
[21:20:29] <mru> the qualcomm mods are disgusting
[21:20:37] <lu_zero> why?
[21:20:45] <ohsix> more like qualcomm is
[21:21:04] <mru> lu_zero: do you expect $bigcorp to do anything nicely?
[21:21:21] <ohsix> expedient and disposable is their motto
[21:21:33] <Flameeyes> mru: I don't think lu_zero is so naïve
[21:21:40] <mru> nor do I
[21:22:06] <Flameeyes> and you just reminded me of opencryptoki... thanks for killing my possible sleep for the next couple of days
[21:22:45] <lu_zero> ^^;
[21:31:44] <BBB> oh wow I just found a radio station that uses wmavoice - my codec is actually practically useful \o/
[21:32:40] <Flameeyes> BBB: radio station with voice?
[21:32:55] <lu_zero> wmapro with voice?
[21:33:51] <BBB> no wmavoice
[21:36:41] <lu_zero> uhm
[21:36:56] <lu_zero> mru: http://ffmpeg.pastebin.com/dgYAxSFQ <- would be useful?
[21:37:51] <mru> no
[21:38:08] <mru> the files are always there
[21:38:27] <mru> -include means don't error if file doesn't exist
[21:38:29] <lu_zero> except when you have the same code mapped in different places
[21:38:32] <lu_zero> I know
[21:38:33] <mru> huh?
[21:38:45] <lu_zero> current situation
[21:38:46] <mru> if the files aren't there, something is horribly wrong
[21:39:00] <mru> what problem are you trying to solve?
[21:39:01] <lu_zero> ffmpeg tree exported to msys in a box
[21:39:12] <lu_zero> msys is dog slow
[21:39:32] <lu_zero> problem at hand : issue make clean w/out waiting for ages
[21:39:44] <mru> I don't see why that makes a difference
[21:39:49] <mru> did you delete the files?
[21:39:50] <lu_zero> solution: run make clean in the host, not the guest
[21:40:19] <lu_zero> the files are there but the paths are wrong for the host and right for the guest
[21:40:24] <JEEB> make distclean is slow for me sometimes, but also fast sometimes :/ I do know that it's lolslow at configure tho @ msys
[21:40:26] <lu_zero> and. now I'm puzzled
[21:41:33] <lu_zero> http://ffmpeg.pastebin.com/cKgvQxiC
[21:41:46] <lu_zero> what as expects to get those ?
[21:42:19] <mru> binutils 2.16 or other ancient version?
[21:43:12] <lu_zero> codesourcery 2.19.something
[21:43:22] <mru> that should be recent enough
[21:43:28] <lu_zero> indeed
[21:43:47] * lu_zero is really spending too much time on getting bada working =P
[21:44:31] <mru> windows-only compiler?
[21:45:44] <lu_zero> mru: I have built it on linux from sources but seems there are discrepancies
[21:45:49] <roxfan> maybe that compiler doesn't support UAL for vfp code
[21:46:04] <roxfan> or just doesn't support ual
[21:46:08] <lu_zero> it's the assembler puking
[21:46:11] <mru> the error message suggests it does support ual
[21:46:20] <mru> it would say invalid instruction name or something otherwise
[21:46:27] <roxfan> vpop is pretty basis
[21:46:28] <lu_zero> just the asflags are wrong
[21:46:29] <roxfan> basic
[21:46:49] <mru> lu_zero: it needs -mfpu=foo to work of course
[21:46:58] <mru> unless the defaults are sane
[21:47:01] <mru> (unlikely)
[21:47:18] <lu_zero> (exactly)
[21:47:26] <lu_zero> on linux the defaults seem ok
[21:47:36] <lu_zero> on the sdk provided the are...
[21:47:41] <lu_zero> utterly wrong =_=
[21:47:57] <Sean_McG> mru: hrm... same error as the swscale is also @ libavcodec/x86/fft_3dn2.c:157
[21:48:05] <Sean_McG> s/error/warning/
[21:48:48] <mru> that one is at least feasible to convert to yasm
[21:49:52] <BBB> PS was my 3dnow-thingy disabling patch ok?
[21:49:58] <BBB> allows compiling ffmpeg with clang 2.8
[21:50:42] <ruggles> BBB: i was considering trying the shuffle/por thing. i just thought it would be slower. but i should never guess when it comes to asm. :) thanks for the code.
[21:50:56] <BBB> ruggles: was it actually faster?
[21:51:03] <ruggles> haven't tried yet.
[21:51:05] <BBB> oh
[21:51:07] <BBB> :-p
[21:51:21] <ruggles> still working on various versions of abs vs min/max
[21:51:39] <BBB> these things aren't too much effort to try, my take is if you're gonna try to write the fastest code, you should try a few things and make sure your choice is the best
[21:51:47] <ruggles> indeed
[21:51:51] <BBB> but I like your code a lot, ac3enc looks pretty good right now
[21:52:06] <BBB> now if only we could convince peloverde to do something about aacenc
[21:52:21] <BBB> ruggles: any interest in aac? :-p
[21:52:29] <ruggles> thanks. the lastest stuff is to speed up the fixed-point encoder. then i have a quality improvement ready for it.
[21:52:43] * saintd3v eeks
[21:53:26] <ruggles> BBB: i haven't looked into it much. i'm slightly afraid of getting lost in the woods... ;)
[21:53:45] <BBB> saintd3v: :D
[21:54:24] <saintd3v> ruggles: join me, then i'll have company out here.
[21:54:37] <ruggles> so many extensions and mp4 crap. mp4als is bad enough with that stuff. aac takes it to the extreme.
[21:55:02] <saintd3v> ruggles: wouldn't need most of the extensions
[21:55:08] <saintd3v> lc is simple enough
[21:55:23] <BBB> elenril: so about the guid renaming, why the long ff_asf_guid_... prefix?
[21:55:27] <ruggles> it would be nice to learn a little bit about it. we need a better psy model.
[21:55:27] <mru> the good thing about writing an encoder is you get to choose the features you support
[21:55:33] <BBB> elenril: isn't it quite obvious that it's a guid?
[21:55:39] <BBB> I mean, after all it _is_ a guid
[21:55:48] <BBB> like int ff_asf_int_i;
[21:55:56] <saintd3v> ruggles: well it's incomplete
[21:56:03] <BBB> ff_asf_ is debatable because they're non-static, but the int part is a little much
[21:57:44] <ruggles> saintd3v: that much is clear. :)  at first i thought i could reuse it as a secondary psy model for ac3, then i realized it's probably worse than the one already built-in to ac3.
[21:58:10] <saintd3v> i know mostly what needs done to complete the 3gpp psymodel, but i'm wary of just doing another 3gpp clone
[21:58:48] <mru> saintd3v: what would it take to convince you to make it decent?
[21:59:07] <mru> is the issue time or money?
[22:01:14] <BBB> elenril: also, regarding your don't-set-empty-metadata-values, should that be generalized, and should there also be "space-only" detection, e.g. for metadata consisting only of whitespace (\n\r\t )?
[22:01:43] <mru> don't forget form feed and vertical tab
[22:02:02] <kierank> isspace
[22:02:23] <mru> and what do you do with the bell character? make it an audio stream?
[22:02:52] <saintd3v> mru: more knowledge. i'm not confident i know enough about psychoacoustics to be able to implement my own psymodel.
[22:03:12] <kierank> saintd3v: you should get some people from hydrogenaudio
[22:03:14] <mru> so steal one
[22:03:24] <saintd3v> the reason i know what our 3gpp psymodel is missing is because i've gone over the 3gpp source, and the 3gpp spec.
[22:04:40] <BBB> I thought the lame one was pretty good?
[22:04:42] <saintd3v> mru: lame's does a convolution at the end, but i have no idea where the table they use came from, which makes it kind of hard to extend for aac's extra scalefactors.
[22:04:59] <mru> ask them
[22:05:32] <saintd3v> i emailed gabriel. haven't got a reply, guess i should ping him on that.
[22:06:17] <saintd3v> not sure how to get ahold of tak
[22:06:21] <saintd3v> *takehiro
[22:07:40] <ruggles> are orps and por really any different?
[22:07:41] <saintd3v> anyway...i guess i should finish 3gpp
[22:08:49] <_av500_> elenril: got that? a bell char in metadata has to be exported as an audio stream!
[22:09:10] <ruggles> LOL
[22:10:37] <lu_zero> O_o
[22:11:01] <lu_zero> _av500_: uhm mpegts =P
[22:11:49] <saintd3v> ruggles: come get lost with me!
[22:14:16] <ruggles> saintd3v: maybe after i finish ac3 and eac3. my todo list is so long...
[22:15:45] <ruggles> i really want to finish AVFrame in audio codecs, and work on planar audio, generic mixing, and simd sample format conversion.
[22:16:49] <BBB> speaking of the devil
[22:16:50] <BBB> :-p
[22:19:10] <lu_zero> AVFrame audio?
[22:19:19] <lu_zero> or another devil?
[22:19:33] <mru> I guess he means peloverde
[22:23:14] <BBB> lu_zero: can you review anssi's mpegts patches?
[22:23:17] <BBB> I know nothing about mpegts
[22:44:54] <lu_zero> not that I know much more
[22:45:07] <lu_zero> still they look pretty straightforward
[22:45:32] <lu_zero> I wanted to have bcoudu opinion though
[22:52:06] <peloverde> mru: bcoudu: Did either of you guys test that ms adpcm patch?
[22:52:22] <peloverde> Because I'm getting divide-by-zeros because of it
[22:52:41] <mru> which patch?
[22:53:01] <mru> the adpcm in mov one?
[22:53:07] <peloverde> yes
[22:53:28] <bcoudu> yes works in every case here, stream copy as well
[22:53:41] <peloverde> movenc.c:84 with scatter.wav from samples
[22:55:38] <bcoudu> stream copy ?
[22:56:26] <peloverde> yes
[22:59:20] <bcoudu> that's because frame_size is not set
[23:01:06] <peloverde> that's correct
[23:01:15] <peloverde> it worked fine with my patch
[23:01:17] <bcoudu> -            if(!st->codec->frame_size && !av_get_bits_per_sample(st->codec->codec_id)) {
[23:01:17] <bcoudu> +            if(!st->codec->frame_size && !mov_get_lpcm_flags(st->codec->codec_id)) {
[23:01:30] <bcoudu> your patch was broken if you accepted frame_size unset
[23:01:33] <bcoudu> and indeed it was
[23:02:08] <ruggles> BBB: your shuffle/por suggestion is about 12 cycles faster for sse2
[23:02:16] <peloverde> so that makes it error out, how about making it actually copy
[23:02:23] <bcoudu> you can't
[23:02:28] <bcoudu> no frame size no luck
[23:02:35] <bcoudu> you don't know how many samples are in the frame
[23:02:48] <peloverde> the wav plays fine
[23:02:57] <bcoudu> yes because frame size is in extradata
[23:03:04] <bcoudu> read the specs ...
[23:03:32] <peloverde> quicktime can copy it
[23:03:47] <peloverde> I suppose quicktime is wrong too
[23:04:03] <bcoudu> quicktime is right
[23:04:19] <peloverde> <bcoudu> you can't
[23:04:57] <bcoudu> if you don't know the frame size you are going to put wrong values in samples to chunk
[23:08:01] <peloverde> if you want to be constructive and not just be a snotty dick perhaps you should just say that you think the wav demuxer is broken, which is what I think you are trying to say
[23:09:56] <peloverde> furthermore shy should frame_size be used there and not pkt->size?
[23:10:38] <bcoudu> I'm wasting my time with your hacks
[23:10:49] <bcoudu> and you keep being stubborn
[23:11:02] <mru> calm down, both of you
[23:11:20] <mru> calling each other names won't fix the bug
[23:11:42] <bcoudu> and the was demuxer is not broken, you don't need frame size to decode
[23:11:46] <bcoudu> you only need block align
[23:12:31] <peloverde> so whose job is it to set frame_size?
[23:17:45] <peloverde> mru: "you can't" is a misleading non-answer
[23:21:04] <DonDiego> gnite
[23:30:12] <bcoudu> are you stupid or what ?
[23:32:01] <ohsix> i infer that the value may be unknown
[23:32:19] <ohsix> and making one up is wrong
[23:32:50] <peloverde> <peloverde> quicktime can copy it <bcoudu> quicktime is right
[23:32:55] <bcoudu> talk about a waste of time
[23:33:00] <bcoudu> you don't know what you are doing
[23:33:28] <peloverde> how does quicktime get the right answer?
[23:33:57] <bcoudu> because quicktime retrieve the frame size from the wav
[23:36:02] <peloverde> So whose responsibility is it to get this from the wav and put it in frame_size?
[23:43:53] <ohsix> git grep to the rescue
[23:44:37] <ohsix> elementary streams dont have the info