掛 IRC 才注意到這個新聞的 :P
01:38 < andrewrk> did everybody see FLIF in the news today?
01:38 < andrewrk> pretty intriguing
01:39 <+wm4> we laughed at the source code
01:39 <+wm4> (let's say they're not really following good practices)
01:45 < jamrial> durandal_1707: see https://github.com/jamrial/FFmpeg/commit/40fc73db28cd9a0fd4aff4284b23a3f5350490f5
01:45 < jamrial> what i'm doing here is making the function access most linesize, width and height arguments directly from stack
01:46 < jamrial> that way the function can work with only 7 gprs
01:46 < jamrial> you can do the same with the blend stuff you sent a few minutes ago. but again you need to make the pointers the first couple arguments
for those
01:48 < andrewrk> wm4, if the DSP is sound it should be fine
01:48 < andrewrk> bad source code can be fixed
01:48 < andrewrk> easy
01:49 <+wm4> well, at this quality level, I wouldn't be surprised if it's not actually lossless
01:49 <+wm4> but yeah, we'll see
01:50 < andrewrk> what's actually the problem?
01:50 < andrewrk> I'm looking at it right now
01:50 < andrewrk> it looks pretty straightforwar
01:50 < andrewrk> *straightforward
01:51 < fflogger> [newticket] cgbug: Ticket #4903 (FLV regression) created https://trac.ffmpeg.org/ticket/4903
01:51 < andrewrk> I guess more c++ than this crowd (including me) would care for
01:55 < atomnuker> goddamnit
01:55 < atomnuker> max_samples isn't respected for multiple input filters
01:56 < atomnuker> any other way to force filtering only N amount of samples per frame?
01:56 <+wm4> andrewrk: no, it's awful beyond that
01:57 <+wm4> but yeah, maybe the algorithms are fine (apart from the fact that it uses patented algorithms, despite claiming otherwise)
01:58 <@durandal_1707> atomnuker: see what sidechaincompress does, also amerge IIRC
02:06 <@Daemon404> [18:51] < andrewrk> I guess more c++ than this crowd (including me) would care for <-- mixing c/c++ strings, using a vector of strings
for stuff, pollutes the global namespace with generic names
02:06 <@Daemon404> mixes_snake_case_andCamel_case
02:06 <@Daemon404> (within teh same func names)
02:06 <@Daemon404> in general it's all over the place
02:06 < andrewrk> ehh that stuff isn't really a big deal
02:06 <@Daemon404> there's one part where it just copypastes the same code 3-4 times in a row because "it seems to fix it"
02:07 < andrewrk> especially mixing case convention. who cares? the CPU doesn't
02:07 < andrewrk> ok that last thing is suspicious.
02:07 <@Daemon404> look at its commit log.
02:07 <@Daemon404> also i certainly care that it has an actually usable library interface
02:07 <@Daemon404> and has actual checks for failure
02:08 -!- lglinskih_ [~lglinskih@verda.kir.elagin.me] has quit [Quit: This computer has gone to sleep]
02:09 <@Daemon404> VLAs initialized with user provided sizes
02:09 <@Daemon404> asserts used instead of ifs
02:09 <@Daemon404> (im just looking over random files atm)
02:09 < andrewrk> I care about that too, but the guy admits it's work in progress
02:10 <@Daemon404> also the format is not patent free
02:10 <@Daemon404> as the page claims
02:10 < andrewrk> yes that is a big problem