[FFmpeg-devel-irc] IRC log for 2010-09-15

[irc at mansr.com]

[00:58:24] <Compn> quick question
[00:58:37] <Compn> ah no, its too dumb
[00:59:05] <Compn> i thought some hd errors were causing box to restart randomly. i booted to a cd and fixed the errors, now i see the mobo has a bad cap
[00:59:18] <Compn> so , yes, its a bad idea to run with a bad cap
[00:59:27] <Compn> (brown crud on top of cap)
[01:06:08] <drv> the bane of 0x motherboards, i had a couple like that
[04:00:39] <funman> what's the ML thread where av_popcount_c() was discussed?
[04:38:35] <funman> well nevermind, it's faster than __builtin_popcount() (pentium m, gcc 4.4.5-debian)
[04:40:51] <astrange> yeah
[04:41:00] <astrange> gcc emulates such things with function calls into libgcc
[04:41:22] <astrange> and libgcc is frequently badly implemented even besides that
[04:41:37] <funman> well it's also faster when not inline
[04:42:00] <astrange> but i think it should use __builtin_popcount on new enough x86, one-line asm statements are optimized slightly worse than builtin calls
[04:42:25] <astrange> because e.g. they can't be scheduled and asm statements are always assumed to clobber eflag
[04:42:30] <astrange> s
[04:42:55] <funman> there's an instruction for that?
[04:44:08] <astrange> in sse4
[04:44:13] <astrange> otherwise there wouldn't be a builtin
[04:45:50] <funman> what's "cc" for if eflags is always assumed to be clobbered?
[04:46:24] <astrange> other architectures where it isn't assumed, i guess
[04:46:57] <astrange> in RISC fewer instructions do that so being explicit is better
[04:47:50] <CIA-63> ffmpeg: reimar * r25124 /trunk/libavcodec/utils.c:
[04:47:50] <CIA-63> ffmpeg: Check avctx width/height more thoroughly (e.g. all values 0 except width would
[04:47:50] <CIA-63> ffmpeg: have been accepted before).
[04:47:50] <CIA-63> ffmpeg: Also do not fail if they are invalid but instead override them to 0.
[04:47:50] <CIA-63> ffmpeg: This allows decoding e.g. MPEG video when only the container values are corrupted.
[04:47:51] <CIA-63> ffmpeg: For encoding a value of 0,0 of course makes no sense, but was allowed
[04:47:52] <CIA-63> ffmpeg: through before and will be caught by an extra check in the encode function.
[05:01:04] <funman> i'm not sure how that works on ARM
[05:02:00] <funman> the system developer guide says only arithmetic instructions can modify the flags but you can clean the datacache with mrc+bne on arm926ej-s, so (at least) mrc modifies it too
[05:32:26] <funman> astrange: it seems gcc always assumes cc is clobbered on ARM too
[05:40:47] <lu_zero> good morning
[05:43:30] <kshishkov> not for thresh but I'd agree
[05:57:52] <_av500_> +1
[06:02:11] <funman> why not?
[06:18:09] <mru> funman: what does cache cleaning have to do with the flags?
[06:18:56] <funman> i wonder too
[06:19:16] <funman> unless that 'bne' doesn't really read flags
[06:19:45] <funman> just like the 'mrc' doesn't really write r15
[06:20:14] <mru> bne what?
[06:20:41] <mru> conditional instructions read the flags, they don't write them
[06:21:04] <mru> of course using a conditional instruction in inline asm without first setting the flags is probably a bad idea
[06:21:33] <Dark_Shikari> s/a conditional instruction in//
[06:21:33] <funman> check arm926 technical reference manual, end of 2.3.8
[06:21:42] <Dark_Shikari> s/without first setting the flags//
[06:21:58] <funman> well it's explicit
[06:22:00] <mru> cleaning the cache might require a loop
[06:22:04] <funman> This MRC instruction also sets the condition code flags.
[06:23:40] <mru> mrc can write to the flags, yes
[06:23:46] <mru> nothing special about cache cleaning
[06:23:53] <funman> 'can' ?
[06:24:07] <mru> if destination register is coded as r15
[06:24:24] <mru> it writes the flag register, not pc
[06:24:36] <mru> otherwise it writes the specified register and leaves flags alone
[06:25:20] <funman> where did you read this?
[06:25:25] <mru> the ARM ARM
[06:26:08] <funman> ah just found it
[06:26:32] <mru> it's probably the instruction used to transfer vfp status flags
[06:30:13] <mru> btw gcc generates a libgcc call for __builtin_popcount() no matter what I do
[06:30:46] <astrange> with -msse4.2?
[06:30:56] <mru> ah
[06:31:00] <mru> I didn't know it had such a flag
[06:32:10] <Dark_Shikari> Hmm, there seems to be a bug in swscale
[06:32:17] <Dark_Shikari> http://doom10.org/index.php?topic=585.msg3958
[06:32:19] <mru> no kidding
[06:32:31] <Dark_Shikari> when doing rgb -> yv12 and upscaling, it does -> yv12 first, then the upscale
[06:32:35] <Dark_Shikari> resulting in horrible results
[06:32:36] <Dark_Shikari> But only for point scaling.
[06:32:38] <Dark_Shikari> Not for any other method.
[06:32:58] <mru> point sampling is supposed to be horrible
[06:33:06] <Dark_Shikari> That's not the point
[06:33:16] <Dark_Shikari> for point sampling, it does something completely different than for any other method
[06:33:19] <Dark_Shikari> and does it badly
[06:33:29] <Dark_Shikari> point is actually useful for intentionally not interpolating
[06:33:32] <Dark_Shikari> i.e. as part of a more complex filter chain
[06:33:34] <mru> good luck getting a patch past michael
[06:33:44] <mru> in his world, swscale is perfect
[06:35:15] <Dark_Shikari>     } else if (flags&SWS_POINT) { // lame looking point sampling mode
[06:35:16] <Dark_Shikari> lol
[06:35:30] <mru> see, it's intentional
[06:35:35] <mru> you'll never get that fixed
[06:44:43] <KotH> a wonderfull, fresh morning to you all!
[06:45:28] <pJok> godmorgon :)
[06:45:41] * cartman yawns
[06:52:11] <lu_zero> mru: you are optimist =P
[07:02:45] <kshishkov> well, the problem is that it would be much nicer if scaled in yuv444
[07:04:48] <iive> Dark_Shikari: what are the horrible reults? rainbows?
[09:14:49] <mru> typedef void Void;
[09:15:11] <mru> /* Redéfinition du type <b>void</b> (existe sur toutes les plate-formes). */
[09:15:25] <av500> lol
[09:15:32] <mru> ateme mpeg4 decoder
[09:15:41] <av500> why not vVoid, v prefix indicating it being a void type?
[09:25:41] <kshishkov> av500: they are not Hungarians
[09:25:55] <mru> and of course typedef void* Pvoid;
[09:26:45] <cartman> mru: how come you got sources to this stuff damn it :D
[09:26:52] <mru> oh, this is behind #if (defined(_MSC_VER) && !defined(_CVI_) && defined(WIN32) && !PORTABILITY_CHECK && !defined(__PLATFORM__))
[09:26:56] <av500> cartman: work in the industry
[09:27:07] <cartman> av500: pr0ndistry?
[09:27:30] <kshishkov> mru: reminds me of inline asm snippets in certain reference decoder
[09:27:49] <av500> cartman: i have similar code
[09:27:56] <cartman> mru: seeing this code, doesn't it make you tainted, legally?
[09:28:10] <av500> and morally
[09:28:18] <kshishkov> cartman: it does, so he never writes _such_ crap
[09:28:22] <cartman> who cares about morality
[09:28:27] <cartman> kshishkov: good point
[09:28:32] <av500> int i4_idx;
[09:28:40] <av500> aka int i;
[09:28:43] <cartman> that might work in court too lol
[09:37:29] <mru> cartman: tainted how?
[09:38:08] <av500> cartman: i bet he's tied to the chair and they show him single lines only at a time
[09:38:15] <mru> it's not like I'd voluntarily copy any of that code even if I were allowed to
[09:39:10] <mru> av500: good idea, mind if I use it for "interrogation"?
[09:39:37] <av500> sure
[09:55:21] <cartman> mru: tainted as in they might have a fast method to do something and later on you might use a similar method unknowingly
[09:56:06] <kshishkov> cartman: highly unlikely
[09:56:38] <mru> authors are allowed to read other authors' books
[09:56:54] <mru> even if they might get an idea for a plot element doing so
[09:57:10] <cartman> mru: well yeah I just wondered the law perspective
[09:57:20] <kshishkov> read the law them
[09:57:24] <kshishkov> *then
[09:57:49] <cartman> kshishkov: just for this reason samba people won't let you code if you read Windows code
[09:58:40] <kshishkov> cartman: that's a bit different and called "paranoia"
[09:58:58] <cartman> maybe :P
[09:59:34] <kshishkov> just like Debian not allowing projects that don't provide opensource tools for generating tables
[09:59:52] <kshishkov> or data files used by program
[10:00:15] <av500> as long they dont ask for os tools to generate the hw they run on....
[10:00:21] <mru> it's fun to watch them squirm when someone submits a package which includes some photographs
[10:00:52] <av500> they require os tools to recreate the photos?
[10:01:03] <mru> they require the "source code"
[10:01:16] <mru> so I guess I have to include a copy of the actual eiffel tower
[10:01:23] <av500> and the french model :)
[10:01:31] <mru> I'm afraid it won't fit on a single floppy
[10:01:44] <kshishkov> use a deck of punch cards instead
[10:02:02] <mru> punch cards are also floppy
[10:02:30] <kshishkov> everything is floppy when enough force is applied
[10:02:43] <mru> no
[10:02:45] <kshishkov> (and appropriate temperature is choosen)
[10:02:46] <mru> some things shatter
[10:02:57] <mru> and not everything melts
[10:03:57] <kshishkov> well, if you apply force slowly, you can bend a lot of those har things anyway
[10:04:02] <kshishkov> *hard
[10:04:11] <mru> not very far
[10:04:19] <kshishkov> yes
[10:04:49] * kshishkov just tries to recollect what he still remembers from school - seems not too much
[10:05:07] <mru> if it can't be bent 90 degrees without breaking, I don't consider it floppy
[10:05:14] <mru> and without permanent deformation
[10:05:30] <mru> try bending a brick
[10:05:44] <av500> using only willpower
[10:06:01] <kshishkov> av500: using only the Force
[10:06:34] <mru> can use the power of my friend Will who practises martial arts?
[10:06:54] <av500> i fear he Will brick it
[10:07:34] <kshishkov> reminds me of usual trick demonstrated in Russian army - breaking bricks with own head (and those soldiers stay the same after performing it)
[10:07:54] <av500> they were thick as a brick before....
[10:08:28] <mru> kshishkov: heard of Egil Skallagrimsson?
[10:08:37] <kshishkov> mru: of course not
[10:08:58] <mru> http://www.badassoftheweek.com/skallagrimsson.html
[10:10:33] <kshishkov> yes, some Vikings were like that
[10:11:42] <kshishkov> (Swedish Vikings tended to go to the East and formed first Ukrainian government, Noraw Vikings tried to sail far away from their homeland)
[10:12:16] <kshishkov> (that leaves only one country for making reputation in murderers, pillagers and such)
[10:44:02] <lu_zero> ...
[10:44:19] <kshishkov> and so is channel
[11:08:26] <cartman> hard to be on topic around here
[11:08:37] <cartman> so gcc aligns 16 byte these days ha
[11:08:51] <mru> aligns what?
[11:08:58] <mru> and on what architecture?
[11:09:03] <cartman> Linux/x86
[11:09:42] <mru> and the first question?
[11:09:53] <cartman> variables?
[11:10:16] * mru applies -v to cartman 
[11:10:41] <cartman> I can't be verbose :P
[11:10:50] <mru> then at least be precise
[11:11:18] <cartman> trying to be on-topic here :P
[11:11:45] <Dark_Shikari> fun fact: all compilers align about 25% of variables to 16 bytes.
[11:12:11] <cartman> what can you align other than variables? malloc?
[11:12:29] <mru> static or stack?
[11:12:40] <cartman> stack I mean
[11:12:40] <mru> or in proper C parlance, automatic
[11:12:50] <mru> there is no stack in C
[11:12:56] <twnqx> if all variables are aligned to 4 bytes... there's no surprise that every fourth arrives at a 16 byte alignment :P
[11:13:06] <Dark_Shikari> twnqx: thatsthejoke.jpg
[11:13:33] <twnqx> will shorts/chars be 32bit aligned?
[11:13:54] <mru> about half/one-quarter of them
[11:14:03] <mru> actually more than that
[11:14:05] <twnqx> and why did this firewall just crash on me...
[11:14:11] * twnqx waits for the phone to ring
[11:14:50] <cartman> some gcc's align at 4bytes, some do 16 now. Isn't that a compatibility problem?
[11:15:00] <twnqx> no
[11:15:53] <cartman> twnqx: what if I assume 4byte alignment?
[11:16:19] <Dark_Shikari> gcc will align to MIN( MAX( what you tell it to, variable size ), stack alignment of target );
[11:16:23] <Dark_Shikari> end of story
[11:19:40] <twnqx> cartman: for what? you refer to variables by name; if you want to be sure about structs you have to #pragma pack anyway; array elements won't be aligned with holes
[11:20:42] <Dark_Shikari> DECLARE_ALIGNED works on struct elements to guarantee minimum alignment
[11:24:56] <mru> for locals you should use LOCAL_ALIGNED
[11:25:20] <mru> it does the right thing even if the compiler doesn't support over-aligning on stack
[13:04:30] <spaam> http://i.imgur.com/jacoj.jpg  is that mru ? SFW :)
[13:05:14] <mru> impossible, there's no shotgun
[13:05:33] <av500> but he is re-reading the c-standard....
[13:05:51] * mru doesn't need to do that
[13:08:50] <kshishkov> spaam: usually we also ask for sample
[13:09:24] <av500> s/stacktrace/pastebin/
[13:13:11] <kshishkov> av500: stacktrace ~= gdb output
[13:14:37] * kshishkov complains to av500 that something is not working properly and gives link to pastebin copy of Jabberwocky
[14:02:44] <merbzt> omg I hate the discards qualifiers from pointer target type warning
[14:04:55] <merbzt> yey all warnings gone, constified the whole code
[14:05:46] <mru> will you do that for ffmpeg next?
[14:06:44] <merbzt> :/
[14:07:33] <kshishkov> yes, just ask any Diego from Argentina if FFmpeg needs less compiler warnings
[14:07:47] <merbzt> I guess the issue is that string constants are of type const char*
[14:08:34] <merbzt> and sometimes one use them without the const
[14:08:48] <mru> gcc shouldn't warn about that
[14:08:58] <mru> it's much too common a pattern
[14:09:13] <spaam> kshishkov: diego as in diegomax? ;O
[14:09:37] <merbzt> mru: yeah or just a possibility to disable it
[14:09:51] <mru> does it warn?
[14:09:57] <kshishkov> spaam: no, local DonDiego
[14:10:29] <spaam> ok. i tought he was from .de
[14:10:51] <mru> he was born in argentina
[14:10:59] <mru> moved to .de at a young age
[14:11:06] <spaam> ok :)
[14:11:19] <merbzt> mru: well I developed some code outside of ffmpeg, compiled fine without any warnings, then I moved it to the ffmpeg build system and all hell broke loose
[14:11:36] <merbzt> found out my code wasn't that standard compliant also
[14:11:36] <mru> we turn on some extra warnings
[14:12:03] <merbzt> and some standard flag also
[14:12:21] <merbzt> strdup wasn't allowed :)
[14:12:35] <kshishkov> merbzt: -Wall -fpedantic -fDiego
[14:13:00] <mru> no, it's -Wdiego -fdark_shikary -mmichael
[14:13:05] <kshishkov> well, with a lot of str* funcs yoou can have buffer overrun
[14:13:18] <mru> kshishkov: the issue here is malloc
[14:13:59] <kshishkov> mru: I forget about this function since I won't use it unless forced
[14:19:26] <lu_zero> a -Wdiego patch sent to the gcc ml the 1st of april might be interesting
[14:19:55] <lu_zero> (and wouldn't take as much work as a -fdark_shikari)
[14:20:16] <mru> warning: assignments not aligned
[14:20:20] <kshishkov> lu_zero: but it won't optimize as much either
[14:20:23] <mru> warning: line longer than 80 chars
[14:20:56] <mru> warning: expected `.' at end of comment
[14:21:16] <mru> warning: Diego is watching you
[14:22:06] <twnqx> wouldn't -Wdiego enable -Werror?
[14:22:24] <lu_zero> twnqx: no
[14:23:30] <lu_zero> kshishkov: a -fdark_shikari would just feed the asm to yasm
[14:23:46] <kshishkov> lu_zero: -fBBB is enough fo that
[14:23:54] <kierank> what would -ftroll do?
[14:24:06] <mru> try and see
[14:24:18] <kshishkov> kierank: post benchmarks to gstreamer forums
[14:24:19] <lu_zero> kierank: spew warnings and misoptimize code
[14:24:33] <lu_zero> it's enabled by default on most of the gcc builds
[14:24:46] <mru> is there a -fno-troll?
[14:24:49] <av500> kierank: call people idiots
[14:25:02] <mru> av500: only with -mcpu=tegra
[14:25:07] <kshishkov> av500: read warning messages, effectively it does
[14:25:08] <av500> :)
[14:25:32] <kshishkov> mru: -mcpu=loongson2f ?
[14:25:44] <mru> that's trolling in itself
[14:26:07] <lu_zero> mru: on -mcpu=tegra it should keep saying "here I'd use neon giving you 4x speed, I'll keep using SLOW instructions"
[14:26:42] <lu_zero> mru: loongson2f is _that_ problematic?
[14:26:54] <mru> lu_zero: it's a terrible cpu
[14:27:06] <kshishkov> lu_zero: "nothing to optimize for this specific CPU, drop -mcpu completely"
[14:27:22] <kshishkov> mru: but it's nice and warm
[14:27:33] <lu_zero> warm being the selling point?
[14:27:41] <kshishkov> obviously, yes
[14:27:48] <lu_zero> I thought rms was loving it
[14:27:50] <mru> it has lots of fans
[14:28:03] <mru> the small, whiny type
[14:28:09] <kshishkov> mru: better than SheevaPlug then
[14:28:14] <lu_zero> so nooisy
[14:28:16] <av500> lu_zero: yes, the only thing left he can love
[14:28:44] <lu_zero> av500: his girlfriend might say something
[14:28:51] <mru> love is not the emotion involved here
[14:28:58] <kshishkov> lu_zero: there was one guy using Gdium (Loongson 2F-based) at LT
[14:29:33] <lu_zero> the gentoo-mips got some of that cpu iirc
[14:30:02] <kshishkov> yes, look at fate
[14:30:16] <mru> that's not the gentoo-mips lu_zero is talking about
[14:30:48] <thresh> rms has a gf? seriously?
[14:30:53] <lu_zero> I mean the team
[14:31:00] <kshishkov> thresh: FSF
[14:31:01] <mru> thresh: not possible
[14:31:36] <lu_zero> thresh: apparently
[14:37:13] <kshishkov> lu_zero: at least Lenin had no children
[14:38:01] <spaam> kshishkov: lenin was a great man ? :)
[14:38:16] <kierank> this channel has Godwin's Law except instead of Hitler it's a soviet leader
[14:38:58] <kshishkov> spaam: in Soviet Union he was either the god or at least great prophet
[14:39:26] <kshishkov> kierank: would you like to talk about Churchill instead?
[14:39:44] <kierank> kshishkov: yes, why not considering it's battle of britain week
[14:39:48] <kierank> ;)
[14:40:02] <av500> still battlin' over britain?
[14:40:12] <mru> I get the impression people actually liked churchill
[14:40:31] <mru> but that could just be revisionist historians at work
[14:41:13] <kshishkov> well, don't you find heavy smoker simpathetic?
[14:43:18] <Tjoppen> well, more liked than chamberlain
[14:43:26] <av500> richard?
[14:43:34] <mru> richard the third?
[14:44:06] <Tjoppen> neville of course
[14:44:13] <kshishkov> av500: there was foreign affairs minister hated in 1920-30s in USSR
[14:44:24] <av500> kshishkov: stop teaching me history
[14:44:34] <kshishkov> Tjoppen: Nobel Peace prize candidate?
[14:44:49] <Tjoppen> maybe I'm getting it wrong :o
[14:44:59] <kshishkov> av500: well, I can't teach you DSP programming
[14:45:20] <av500> kshishkov: there was stupid actor, hated by everybody...
[14:45:22] <cartman> kshishkov: teach me instead :P
[14:46:10] <kshishkov> cartman: there were no Turks known at least 1500-1600 years ago
[14:46:22] <cartman> kshishkov: I mean the DSP programming part, :)
[14:46:33] <kshishkov> cartman: ask av500 instead
[14:46:39] <cartman> bah
[14:46:50] <av500> kshishkov: he wont be lectured by a serb
[14:46:58] <cartman> av500: nah you are evil :P
[14:47:16] <lu_zero> ^^;
[14:47:20] <mru> av500: perhaps you should show them some videos
[14:47:42] * cartman couldn't care less about nationality
[14:48:04] <kshishkov> Tjoppen: you know, Nobel Peace prize is often awarded controversially. But then I found out it's Norwegians who do judgement.
[14:48:12] <av500> cartman: i was born in frankfurt, so I feel like a ................ i dunno
[14:48:30] <kshishkov> av500: some sort of sausage?
[14:48:31] <cartman> av500: teach me dsp, first of all, what should I learn DSP, teach me
[14:48:54] <mru> cartman: it's easy
[14:48:58] <av500> kshishkov: yes, in vienna
[14:48:59] <mru> 1. take Signal
[14:49:05] <mru> 2. make it Digital
[14:49:10] <mru> 3. Process it
[14:49:17] <av500> 4) profit
[14:49:42] <cartman> whats a signal essentially?
[14:50:36] <mru> anything that can be represented as a sequence of numbers
[14:51:19] <kshishkov> av500: well, I believed that you have sausages for every German city - like Frankfurter, Nueremberger, Sumpfer
[14:51:20] <cartman> what are the properties of "digital" ?
[14:52:00] <kshishkov> cartman: signal is any one-dimensional ordered set of data
[14:52:15] <mru> or more-dimensional
[14:52:16] <kshishkov> cartman: and digital means it can be represented with numbers
[14:52:27] <mru> like I said
[14:52:58] <cartman> ok so whats the basic most simple operation you would apply to a signal ?
[14:53:02] <kshishkov> signal: f(t)
[14:53:19] <mru> the simplest operation?
[14:53:22] <kshishkov> any math operation really
[14:53:25] <mru> why the identity function
[14:53:38] <cartman> f(x) = x ?
[14:53:43] <cartman> uhm no
[14:53:47] <mru> or the f(x) = C function
[14:53:54] <mru> also quite simple
[14:54:01] <mru> doesn't even need a signal
[14:54:17] <cartman> ok so there must be some operations that are useful for image/video processing
[14:54:45] * mru points at ffmpeg
[14:54:54] <cartman> say I have a bmp file
[14:55:02] <cartman> what would be my signal as input?
[14:55:03] <mru> ffmpeg -i foo.bmp
[14:55:04] <av500> bmp was in the 80s
[14:55:28] <cartman> see av500 , thats why you can't teach :P
[14:56:03] <cartman> mru: ok so the BMP x,y & RGB data, how can you represent it as a signal?
[14:56:05] <cartman> can you?
[14:56:22] <mru> uint8_t image[]
[14:56:30] <kshishkov> it's just f(x,y) = {R, G, B}
[14:56:49] <cartman> ok
[14:57:06] <cartman> starting to make sense :P
[14:57:18] <cartman> how do you make this data digital ?
[14:57:23] <av500> it is
[14:57:34] <mru> if it's in a computer, it's by definition digital
[14:57:40] <cartman> already numbers ok
[14:57:42] <mru> otherwise you need an ADC
[14:57:43] <av500> it was analog on the canvas it was photographed from
[14:57:58] <kshishkov> av500: it's been drawn in M$ Paint
[14:58:09] <cartman> so give me an example of processing function for this data?
[14:58:23] * mru points at ffmpeg
[14:58:41] <cartman> ffmpeg does everything, I am trying to understand basics :)
[14:58:50] <kshishkov> cartman: f(x) = x/2, it will make it darker
[14:58:52] <cartman> I could change R,G,B values for each point maybe
[14:58:57] <cartman> right
[14:59:06] <cartman> how does DSP help me here? :-)
[14:59:16] <cartman> I could do this without DSP too
[14:59:27] <kshishkov> this _is_ DSP by definition
[14:59:36] <cartman> I mean a DSP unit :)
[14:59:40] <mru> cartman: does your P stand for Processing or Processor?
[14:59:49] <cartman> Processor sorry
[15:00:10] <mru> that's just a computer that's particularly good at processing signals
[15:00:19] <cartman> ok like a SIMD unit
[15:00:20] <kshishkov> cartman: load data into it, set processing function, get data back. Good DSP should do it faster than main CPU
[15:00:31] <mru> or with less power
[15:00:40] <cartman> kshishkov, mru , av500 ok thanx, not that hard to understand :-)
[15:00:57] <cartman> f(x) = x/2 for example, whats this called, DSP function?
[15:01:30] <kshishkov> probably
[15:01:39] <cartman> ok
[15:01:46] * mru calls it an order-1 polynomial
[15:01:58] <cartman> DCTs, FFTs are such functions too ?
[15:02:06] <kshishkov> yes, DSPs are programmable devices after all
[15:02:17] <cartman> alright
[15:02:19] <cartman> thanks
[17:38:37] <CIA-63> ffmpeg: mstorsjo * r25125 /trunk/libavformat/ (sdp.c rtpenc.c rtpdec.c rtp.c): Handle G.722 in RTP, and all the exceptions mandated in RFC 3551
[17:41:02] <CIA-63> ffmpeg: mstorsjo * r25126 /trunk/libavformat/rtsp.c: rtsp: Handle standard assigned codec names for private payload types, too
[18:43:17] <mru> peloverde: ping
[19:13:24] <mru> hmm, does ffmpeg support jpeg-xr at all?
[19:13:38] <mru> I don't see it, but it could be masquerading under another name
[19:28:32] <peloverde> mru: pong
[19:28:48] <mru> what shape is aacenc in nowadays?
[19:31:02] <peloverde> if given sufficient (but not necessarily excessive) bitrate the psuedo CBR stuff works reasonably well for mono
[19:31:26] <peloverde> stereo has been getting better too but is not as good
[19:31:30] <peloverde> mid/side detection needs to be adjusted
[19:31:42] <Dark_Shikari> mru: hexagonal
[19:32:02] <peloverde> saintd3v had some lame-derived psystuff that he was working on
[19:33:11] <Dark_Shikari> well I doubt making it more lame will make it better
[19:33:37] <mru> ha ha ha
[19:34:35] <Dark_Shikari> "very punny"
[19:34:53] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/IncrediblyLamePun
[19:40:14] <DonDiego> jannau: say, what happened with the latm stuff?
[19:40:33] <mru> still as retarded as ever
[19:59:51] <DonDiego> no matter how retarded it is, ffmpeg needs to support it
[20:00:02] <DonDiego> we need to put libfaad2 out of service
[20:01:04] <kierank> get michael to come up with a non-hacky way of doing chained demux
[20:01:37] <BBB> why michael
[20:01:49] <kierank> because if he wrote it he can't criticise it ;)
[20:03:06] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/iHmvQEsx what's wrong here?
[20:03:12] <BBB> Dark_Shikari: my 8x8 function passes make fate
[20:03:21] <peloverde> I thought people begrudgingly agreed to let the outer demuxer spin it manually like dv
[20:03:22] <BBB> Dark_Shikari: my 16x16 function does not... why?
[20:06:27] <kierank> peloverde: iirc there's still a problem when you have multiple packets per frame. (like 2 audio streams in one latm frame)
[20:10:46] <peloverde> kierank: i thought we were going to focus on one stream first, many "decoders" that "support latm" only support singlestream
[20:11:15] <Dark_Shikari> BBB: don't you mean jne?
[20:12:36] <Dark_Shikari> also, are you sure r1 and r2 aren't modified during hadamard8x8_diff?
[20:12:54] <kierank> peloverde: i suppose we could do that.
[20:17:24] <bcoudurier> I agree with peloverde
[20:17:29] <BBB> Dark_Shikari: I replaced it (as a hack) with mov r1, r1m (same for r2, and then the chahges) but the output is unmodified
[20:17:48] <BBB> as far as I understand, h (r4) is either 8 or 16
[20:18:01] <BBB> isn't jnz the same as jne?
[20:19:57] <jenk> what args do they take?
[20:20:08] <jenk> doesnt jne have two operands
[20:20:19] <cartman> av500: do you work for archos by any chance?
[20:20:32] <mru> now the penny drops...
[20:21:00] <BBB> my penny?
[20:21:04] <BBB> ooo a penny
[20:21:09] * BBB grabs it and buys candy
[20:23:38] <_av500_> cartman: yep
[20:24:05] <cartman> _av500_: can I ask you about one of your Android tablets? A friend wants to buy one.
[20:25:03] <DonDiego> gnite
[20:25:41] * cartman shows _av500_ a penny
[20:25:59] <j0sh> hey guys
[20:26:08] <j0sh> wanna help me figure out a topic for my school thesis
[20:26:14] <j0sh> ^^ could be integrated into ffmpeg
[20:26:39] <j0sh> i want to make something useful, not just write a paper...
[20:26:44] <wbs> j0sh: bachelor's or master's thesis?
[20:26:48] <j0sh> master's
[20:26:57] <wbs> nice. :-)
[20:27:04] <j0sh> although they wont mail me either until i finish the thesis (dual degree program)
[20:27:23] <wbs> yeah, things used to be like that here, too
[20:27:40] <j0sh> yeah
[20:28:16] <j0sh> i was thinking of maybe a deinterlacer, using motion data from MVs or whatever
[20:28:16] <wbs> but due to eu-standardization and such, people nowadays have to finish the bachelor's first
[20:28:24] <j0sh> but is yyadif really needed?
[20:29:35] <cartman> _av500_: one small q., get up
[20:33:31] <j0sh> maybe some work with snow?
[20:34:43] <kierank> you could try and improve nnedi
[20:36:13] * j0sh googles it
[20:36:48] <BBB> hm, figured out one half of that
[20:36:57] <j0sh> http://forum.doom9.org/showthread.php?t=129953
[20:36:58] * BBB kicks 4, 6 instead of 5, 6 while accessing r4
[20:37:57] <j0sh> kierank: that looks promising, thanks
[21:27:11] <j0sh> pengvado: how long did it take you to RE nnendi?
[21:30:26] <Dark_Shikari> a lot of it was made easier by the fact that the original author posted the algorithm...
[21:32:51] <j0sh> Dark_Shikari: where? i havent been able to find it
[21:34:23] <Dark_Shikari> it was in the nnedi thread
[21:34:27] <Dark_Shikari> it was a paragraph or so outlining how it worked
[21:37:00] <CIA-63> ffmpeg: jbr * r25127 /trunk/tests/audiogen.c:
[21:37:00] <CIA-63> ffmpeg: Allow audiogen to take commandline parameters for sample rate and number of
[21:37:00] <CIA-63> ffmpeg: channels.
[21:44:58] <bcoudurier> is there code available for nnedi ?
[21:46:03] <Dark_Shikari> pengvado released his own version
[21:46:05] <Dark_Shikari> it's 2x faster
[21:46:34] <j0sh> http://akuvian.org/src/x264/nnedi.tar.bz2
[21:46:37] <bcoudurier> awesome
[21:46:46] <j0sh> http://forum.doom9.org/showthread.php?p=1427793#post1427793
[21:47:19] <bcoudurier> ah that's not the deinterlacer :(
[21:47:31] <Dark_Shikari> nnedi isn't a deinterlacer
[21:47:34] <Dark_Shikari> it's an edge-directed interpolator
[21:47:47] <Dark_Shikari> NNEDI is part of a balanced diet^H^H^H^Hdeinterlacer.
[21:48:11] <pengvado> you're underselling it, unless tritical has released an update
[21:48:12] <pengvado> 4x
[21:48:35] <Dark_Shikari> oh.  4x then
[21:48:44] <bcoudurier> anyway that's awesome I'm gonna write a filter from it
[21:48:45] <pengvado> well, if you run it on really big nets, then it cache thrashes all over and is only 2x
[21:49:01] <Dark_Shikari> and it catches dolphins.  rather annoying problem with larger nets
[21:52:07] <pengvado> the algorithm he posted was for nnedi1. so that was helpful, but not nearly a substitute for REing nnedi3.
[21:52:14] <Dark_Shikari> ah.
[21:52:22] <Dark_Shikari> is yours comparable to 1 or 3?
[21:53:52] <pengvado> 3
[21:54:04] <Dark_Shikari> oh, so you RE'd 3 too
[21:54:40] <pengvado> I didn't RE 1
[21:54:46] <Dark_Shikari> ah k
[21:54:51] <Dark_Shikari> how is 3's algorithm different?
[21:55:00] <pengvado> I took the brief explanation of v1, which helped me understand the asm of v3
[21:56:29] <pengvado> v1 classifies the neighborhood into a bunch of discrete categories, each of which has its own a 2-hidden-layer net with a bunch of neurons
[21:57:52] <pengvado> v3 does soft classification. the categories have only 1 neuron each, but they're all run all the time, and the classification part determines the relative weights.
[21:58:59] <j0sh> and all from looking at disassembly... that's crazy
[21:59:29] <pengvado> j0sh: judging from my git timestamps, it took 10 consecutive hours before I had a perfect duplicate of the existing algorithm, and then I published my faster version 20 days later.
[22:00:20] <Dark_Shikari> bit-exact duplicate?
[22:00:23] <pengvado> yes
[22:00:49] <j0sh> wow
[22:02:01] <Dark_Shikari> impressive.
[22:02:34] <Dark_Shikari> >soft classification
[22:02:38] <Dark_Shikari> so in other words its context mixing.
[22:03:19] <Dark_Shikari> doesn't that make it much much slower?
[22:03:21] <Dark_Shikari> or are there fewer contexts?
[22:05:42] <pengvado> v1 has 64 contexts
[22:06:03] <pengvado> v3 has several settings, the smallest of which is 16 contexts
[22:07:17] <jannau> hmm, DonDiego has left. I'm trying to avoid to working on LATM. I need working LATM in mpeg-ts this month for MythTV
[22:07:49] * mru fails to reconcile those statements
[22:07:57] <Dark_Shikari> pengvado: so it's 16x slower ?
[22:08:03] <Dark_Shikari> due to mixing 16 contexts?
[22:08:10] <Dark_Shikari> or does it avoid mixing ones that aren't high-weighted?
[22:08:15] <pengvado> 16 contexts of 1 neuron each, as opposed to 1 of 16
[22:08:38] <jannau> mru: I'm procrastinating
[22:08:56] <mru> ah, makes sense
[22:09:46] <jannau> btw git cherry-pick is not much faster on tmpfs. maybe 15%
[22:09:56] <mru> it was for me
[22:11:02] <CIA-63> ffmpeg: cehoyos * r25128 /trunk/ (configure libavcodec/libmp3lame.c):
[22:11:02] <CIA-63> ffmpeg: Allow float values for libmp3lame quality.
[22:11:02] <CIA-63> ffmpeg: Patch by James Darnley, james D darnley A gmail
[22:11:43] <jannau> mru: what fixups were you planning for the ffmpeg+libswscale merge?
[22:12:55] <jannau> I have a script for merging both repos with interleaved history which fixes the libpostproc move to libavcodec in 2003
[22:14:00] <mru> that part is trivial
[22:14:49] <mru> it's the duplicated files that should be fixed
[22:14:59] <mru> same file committed to two locations
[22:15:24] <mru> probably result of cvs repo hacking
[22:17:19] <jannau> which files? postproc* has such commits. the early commits live both in libswscale and in libavcodec/libpostproc
[22:17:31] <mru> that may have been the ones
[22:17:42] <mru> did you manage to fix them automatically?
[22:17:51] <jannau> that's fixed properly
[22:18:05] <jannau> not automatically
[22:18:08] <mru> it wasn't obvious to me what proper was
[22:21:05] <jannau> I removed the commits in the ffmpeg repo and redid the three move commits in a single commit
[22:21:42] <mru> of course, no matter what you do, those old versions will fail to build
[22:22:01] <mru> because no tree ever looked like that at the time
[22:23:22] <jannau> I think the changes to libavcodec/libpostproc prior to svn rev 1586 are caused by repo hacking to preserve the history
[22:24:39] <jannau> the tree looks different but it should build since the other are not in the Makefiles
[22:24:52] <jannau> I should verify that
[22:28:03] <bcoudurier>     int h1 = width;
[22:28:04] <bcoudurier>     int w1 = height;
[22:28:13] <bcoudurier> pengvado, is that normal or a typo ?
[22:28:39] <Dark_Shikari> lol?
[22:30:35] <pengvado> that's normal. it's doing a transpose.
[22:30:46] <Dark_Shikari> ah.
[22:30:53] <jannau> gcc 4.4 doesn't like early revisions. "mpegaudiodec.c:2376: error: label at end of compound statement"
[22:32:30] <Dark_Shikari> FFFFF goddamn C rules about unsigned got me again
[22:32:42] <Dark_Shikari> I fucking hate how uint32_t * int32_t is promoted to uint32_t
[22:50:01] <pengvado> just updated http://akuvian.org/src/x264/nnedi.tar.bz2 with threading support
[22:50:27] <Dark_Shikari> oh wow.  nice
[22:50:50] <j0sh> cool
[22:51:28] <pengvado> still doesn't scale perfectly. if you're doing anything other than grayscale, it would be better to run multiple planes in parallel, but I can't easily implement that inside nnedi.c
[22:52:33] <j0sh> what needs to be done to make it a deinterlacer?
[22:54:03] <pengvado> upscale_threaded() is a deinterlacer, though it requires the input image to be padded, i.e. it writes beyond the edges
[23:01:24] <j0sh> hmm you sure you updated it? i dont see any thread related code
[23:27:14] <pengvado> yes I'm sure