[Ffmpeg-devel-irc] ffmpeg-devel.log.20151003

[burek]

[01:14:12 CEST] <J_Darnley> When gcc is calculating the "arguments" to an asm block, does it follow the standard array rules?
[01:15:04 CEST] <J_Darnley> As in: A is defined to be an array of int16_t
[01:15:19 CEST] <Compn> DHE : bleh , that code is all hard to read :P
[01:15:32 CEST] <Compn> not your patch, but the file
[01:15:33 CEST] <J_Darnley> A + 32 would be the start plus 64 bytes, right?
[01:17:40 CEST] <DHE> Compn: I give my patch the WorksForMe rating. but I didn't test it with the subtitles as I don't have any
[01:24:30 CEST] <J_Darnley> Of course it does.  Why would it do anything else.
[01:28:23 CEST] <Compn> DHE : you moved the av_freep inside a bracket, i assume this move is correct but .... worries me (i am not a programmer as well)
[01:35:08 CEST] <DHE> Compn: I pulled the malloc in as well. The alternative was to allocate memory that might go unused and that seemed silly
[01:35:40 CEST] <DHE> allocation was in the first hunk
[01:41:02 CEST] <J_Darnley> 2 inline uses of constants down...
[02:02:22 CEST] <BBB> Gramner: is pinsrw slower than movd?
[02:07:46 CEST] <atomnuker> I give up, there
[02:07:59 CEST] <atomnuker> is no way to get matched up samples
[02:08:46 CEST] <BBB> what are you trying to do?
[02:08:57 CEST] <atomnuker> measure SSIM of two audio streams in lavfi
[02:09:26 CEST] <atomnuker> problem is there's no way to get them matched up well enough
[02:10:58 CEST] <atomnuker> so I'm thinking I might have to resort to actually using lavc to decode the streams and then try to match them up
[02:11:57 CEST] <durandal_1707> match up means what?
[02:12:13 CEST] <atomnuker> time-wise
[02:13:07 CEST] <atomnuker> you don't want to have one stream delayed by some tens of miliseconds because then you can only measure long term harmonic content at best
[02:14:21 CEST] <atomnuker> just mixing the streams using amix will result in an echo, and that echo is different for each encoder (aac, opus, mp3)
[02:14:34 CEST] <BBB> lol
[02:14:38 CEST] <BBB> that is so hard
[02:14:42 CEST] <durandal_1707> you mean shift one stream by some numbers of samples?
[02:14:58 CEST] <BBB> Im surprised theres no scripts to help you do that
[02:14:59 CEST] <BBB> or filters
[02:15:05 CEST] <BBB> also, ssim & hm ...
[02:15:12 CEST] <BBB> I didnt know you could use that for audio
[02:15:40 CEST] <atomnuker> that's the easy part, as long as they're matched up I'm getting nice results
[02:16:01 CEST] <atomnuker> I should try decoding them to wavs and using audacity to match them up
[02:17:14 CEST] <durandal_1707> huh what audacity uses for matching up?
[02:17:37 CEST] <atomnuker> nothing, you have to do that manually
[02:18:08 CEST] <durandal_1707> with what?
[02:18:13 CEST] <atomnuker> seek to the nearest non-zero sample and cut off anything before
[02:18:37 CEST] <BBB> cant you just use various offsets and use the one with max ssim?
[02:18:42 CEST] <BBB> like a motion search
[02:19:06 CEST] <atomnuker> shit, I totally forgot I could just use the same thing AAC-LTP uses
[02:19:27 CEST] <DHE> Compn: any other concerns?
[02:20:35 CEST] <jamrial> BBB: for position 0 it most likely is slower
[02:22:12 CEST] <durandal_1707> atomnuker: don't kill the code, I want to use it :)
[02:25:44 CEST] <atomnuker> not poisoning anything, just a small static autocorrelation function is all that's needed to get the offset :)
[02:34:53 CEST] <TD-Linux> atomnuker, you're trying to use SSIM on audio?
[02:36:21 CEST] <TD-Linux> your results will be 100% nonsensical anyway
[02:39:58 CEST] <atomnuker> huh, why?
[02:41:21 CEST] <atomnuker> TD-Linux: http://www.researchgate.net/publication/4333525_Audio_quality_assessment_using_the_mean_structural_similarity_measure
[02:41:45 CEST] <atomnuker> seems to follow subjective results well enough to be more useful than PSNR
[02:43:37 CEST] <TD-Linux> atomnuker, ugh, SSIM has weights that are tuned from image perception
[02:43:58 CEST] <TD-Linux> it might do better than PSNR but that's just totally random chance (PSNR is also nearly useless for audio quality comparison)
[02:44:02 CEST] <TD-Linux> PEAQ is a lot better
[02:45:26 CEST] <TD-Linux> ah I see they at least retrained it in that paper, but still no comparison to PEAQ?
[02:48:17 CEST] <atomnuker> you know, screw this, I'm making my own metric
[02:49:14 CEST] <atomnuker> I'll dig up some stuff I did using libfftw3
[02:50:55 CEST] <atomnuker> I guess finding the peaks of well matched up frames and measuring the difference in the noise around them should be a good metric
[02:52:31 CEST] <TD-Linux> atomnuker, how much science are you after? you might want to ask jmspeex
[02:54:01 CEST] <durandal_1707> autocorrelation should be easily done with lavc fft
[02:57:25 CEST] <atomnuker> TD-Linux: enough science to be good enough to tell 320kbps vs 50kbps mp3 would be good enough as a starting point
[02:57:52 CEST] <atomnuker> since the peaks especially around the mid frequencies are the last thing to go they're a good reference point
[02:59:02 CEST] <atomnuker> It sounds logical to me at 2 am, surely it'll work
[03:00:14 CEST] <TD-Linux> yeah, I guess? or you could instead download afsp with pqevalaudio from ftp://ftp.tnt.uni-hannover.de/pub/audio/AFsp/
[03:00:47 CEST] <TD-Linux> (warning: nonfree software)
[03:11:12 CEST] <atomnuker> TD-Linux: just tested that
[03:11:30 CEST] <atomnuker> for one it's barely sensitive enough to detect 128kbps vs 530kbps aac
[03:11:54 CEST] <TD-Linux> that's because there's little audible difference
[03:12:18 CEST] <atomnuker> for two it's showing that 20kbps file actually has a higher score than a 40kbps file
[03:12:26 CEST] <atomnuker> and believe me the difference is day and night
[03:12:37 CEST] <TD-Linux> well yeah that's true.
[03:13:00 CEST] <TD-Linux> good luck on your better metric :) there is a reason that people don't use objective tests much in audio
[03:13:14 CEST] <TD-Linux> opus was developed mostly only with listening tests
[03:19:43 CEST] <atomnuker> TD-Linux: yeah, it's probably better to let loose some ABX crazies to tune encoders
[03:20:32 CEST] <atomnuker> they'll never accept a machine which can detect warm analogue tube sound anyway
[03:21:49 CEST] <TD-Linux> I'm failing to parse what you're trying to say there
[03:24:25 CEST] <Compn> DHE : nope! :)
[03:24:50 CEST] <Compn> curious what the /0 filename stuff is about
[03:24:56 CEST] <Compn> i know p is set to /0
[03:24:59 CEST] <Compn> but uhh
[03:25:05 CEST] <Compn> no clue. it baffles me
[03:25:14 CEST] Action: Compn plays games instead of learning c
[04:06:09 CEST] <BBB> atomnuker: just write a script that automatically posts to hydrogenaudio and parses comments
[04:06:25 CEST] <BBB> atomnuker: maybe a little higher latnecy than what youre used to, but ...
[04:32:25 CEST] <rcombs> atomnuker: if removing silence at the beginning is good enough, you could try lavfi's silenceremove filter?
[09:33:17 CEST] <cone-286> ffmpeg 03Vicente Olivert Riera 07master:3f1f6053013d: configure: address a copy-paste typo
[09:33:17 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:59b55619b6ed: Merge commit '3f1f6053013d0015e9f115a91a11744807649a07'
[09:53:22 CEST] <cone-286> ffmpeg 03Vittorio Giovara 07master:1aa24df74c05: lavu: Deprecate AVFrame.error[]
[09:53:23 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:5fa5e73e81f1: Merge commit '1aa24df74c052a73175c43e57d35b4835e537ec8'
[11:57:54 CEST] <cone-286> ffmpeg 03Michael Niedermayer 07master:85c92789b604: avcodec/h264_ps: Fix copying oversized pps&sps data
[12:20:58 CEST] <cone-286> ffmpeg 03Rodger Combs 07master:9825a24e5b1c: lavf/utils: avoid giving up probing early with long subtitle events
[12:27:28 CEST] <cone-286> ffmpeg 03Vittorio Giovara 07master:9a3202a98b2e: Screenpresso SPV1 decoder
[12:27:29 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:4d2160c99a00: Merge commit '9a3202a98b2e095b54dd784c3e01a09a676fc3fa'
[12:32:44 CEST] <cone-286> ffmpeg 03Luca Barbato 07master:8ae1d87a2440: build: Add support for known custom allocators
[12:32:45 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:98ca981a238c: Merge commit '8ae1d87a2440cea0564efe2a6c9c223478a05f44'
[12:42:26 CEST] <cone-286> ffmpeg 03Alexandra Khirnova 07master:d0a3e89d41b0: dcadec: make a number of samples per subband per subsubframe a named constant
[12:42:27 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:a11741c29393: Merge commit 'd0a3e89d41b05f9ed0e7401c352b60ed4f4d1ed5'
[12:43:33 CEST] <cone-286> ffmpeg 03Luca Barbato 07master:74942685cb45: hls: Check av_opt_set_dict return value as well
[12:43:34 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:4e67382d7298: Merge commit '74942685cb457c01937686892878403a409baf27'
[12:43:51 CEST] <cone-286> ffmpeg 03Yu Xiaolei 07master:eb02387add35: x264: Expose the NV21 input support
[12:43:52 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:f5af92edb921: Merge commit 'eb02387add350f2b34a3e61539fe25ec6213eb18'
[12:46:07 CEST] <cone-286> ffmpeg 03Derek Buitenhuis 07master:380146924eca: x264: Add option to force IDR frames
[12:46:08 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:cda503a1b92c: Merge commit '380146924ecad2e05e9dcc5c3c2e1b5ba47c51e8'
[12:47:29 CEST] <cone-286> ffmpeg 03Joseph Artsimovich 07master:bfe1cd80ebea: dnxhddata: Fix 10-bit DNxHD quant matrices
[12:47:30 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:ed11e8966c12: Merge commit 'bfe1cd80ebeab58cbc1c91ac766a96fce8e4ec1e'
[12:47:40 CEST] <cone-286> ffmpeg 03Jeremy James 07master:cc320296ab43: dnxhddata: Fix cid 1260 luma and chroma tables
[12:47:41 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:092d22ea755a: Merge commit 'cc320296ab438dfe3178f0e1f775af955fe6c064'
[12:48:47 CEST] <cone-286> ffmpeg 03Jeremy James 07master:1fb63d6f43c3: dnxhddata: Deduplicate dnx100 tables
[12:48:48 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:6411ac68865d: Merge commit '1fb63d6f43c348e9c990fa6f7c1bd43f22bc2389'
[12:49:32 CEST] <cone-286> ffmpeg 03Christophe Gisquet 07master:e54d7e4e8ef7: dnxhddata: Deduplicate cid 1256 chroma table
[12:49:33 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:6b849211bc2a: Merge commit 'e54d7e4e8ef7d778e2ddc5a60bf7307ed55d6333'
[13:06:35 CEST] <cone-286> ffmpeg 03Rodger Combs 07master:14221b2dd913: lavf/hls: allow subtitles to be read despite incomplete handling
[13:38:05 CEST] <durandal_1707> BBB: do you see way how to simd atadenoise code?
[13:57:39 CEST] <BBB> hm...
[13:58:01 CEST] <BBB> so atadenoise averages a pixel over multiple frames at the same source position up to a threshold of N pixel diff?
[13:59:34 CEST] <BBB> yes that can be simded, its not exactly trivial but it can be done
[14:00:37 CEST] <BBB> so the absdiff is quite simple, assume ssse3 for now, just punpcklbw with a zero, psubw to get diff, pabsw to get absdiff, pcmpgtw to get threshold
[14:00:54 CEST] <BBB> and then mask against that before adding to sum (pandn)
[14:01:10 CEST] <BBB> then the division is harder, look into FASTDIV on how to do multiply-directed divisions
[14:01:28 CEST] <BBB> assuming r/l are low, you should be able to do something
[14:04:36 CEST] <BBB> https://chromium.googlesource.com/webm/libvpx/+/master/vp8/encoder/temporal_filter.c#366 is an example of how to do a division without using a /
[14:04:40 CEST] <BBB> durandal_1707: ^^
[14:06:09 CEST] <durandal_1707> r+l+1 is lower than 256
[14:06:33 CEST] <durandal_1707> thanks
[14:06:53 CEST] <BBB> ok, so this wont be the simplest simd ever, but I think you should have some starting points now :)
[14:07:18 CEST] <BBB> so obviously you wouldnt do this per pixel over each buffer, rather youd do it per block or per line or so over each buffer
[14:07:22 CEST] <BBB> since otherwise simd doesnt help
[14:07:25 CEST] <BBB> but the rest is fairly easy
[14:40:15 CEST] <cone-286> ffmpeg 03Ganesh Ajjanagadde 07master:0493e42eb2f9: avcodec/x86/hpeldsp_rnd_template: silence -Wunused-function on --disable-mmx
[14:44:15 CEST] <BBB> so should some of these unused variable with e.g. pthreads disabled be placed under #if HAVE_THREADS?
[14:44:18 CEST] <BBB> or is av_unused ok?
[14:44:36 CEST] <nevcairiel> whatever seems better in the context
[14:44:50 CEST] <nevcairiel> jsut adding ifdefs for a variable def seems overkill
[14:45:02 CEST] <nevcairiel> but if you can move the var under an existing one, that might work
[14:45:25 CEST] <BBB> I meant more for init_thread_context, update_thread_context in each codec
[14:45:29 CEST] <BBB> theres usually a bunch of functions
[14:45:41 CEST] <BBB> ganesh patches mark them as av_unused
[14:45:47 CEST] <BBB> Im wondering if #if HAVE_THREADS is better
[14:50:13 CEST] <nevcairiel> av_unused wouldnt catch a function that becomes truely unused
[14:54:44 CEST] <cone-286> ffmpeg 03Michael Niedermayer 07master:de2f5316991e: configure: Change screenpresso_decoder to select zlib instead of dep
[15:10:11 CEST] <cone-286> ffmpeg 03Henrik Gramner 07master:99982524f93a: checkasm: Remove use of deprecated av_set_cpu_flags_mask()
[15:10:52 CEST] <BBB> what is -Waddress
[15:11:01 CEST] <BBB> it sounds creepy
[15:11:29 CEST] <Gramner> wad dress?
[15:13:03 CEST] <BBB> oh Ive seen it, I actually thing its a sensible warning
[15:32:21 CEST] <BBB> nevcairiel: so& ganesh commit?
[16:05:26 CEST] <cone-286> ffmpeg 03Paul B Mahol 07master:13090895cf1c: avfilter/vf_tinterlace: add mergex2 mode
[16:34:20 CEST] <cone-286> ffmpeg 03Carl Eugen Hoyos 07master:7c94cfa262ad: lavc/options_table: Add option flags to the truncated flag.
[16:36:11 CEST] <cone-286> ffmpeg 03Carl Eugen Hoyos 07master:64508b9af240: configure: Remove --disable-avutil which has no effect from help output.
[17:51:25 CEST] <cone-286> ffmpeg 03Ganesh Ajjanagadde 07master:8dc6e92c3dc6: ffplay: more robust mutex, condition variable handling
[18:43:42 CEST] <kurosu> for some reason, I received from the ml "Message has implicit destination" when I ran git send-email (which uses gmail and msmtp)
[18:44:10 CEST] <kurosu> anyone has an idea why that would happen?
[18:44:37 CEST] <Daemon404> did you use bcc instead of to?
[18:44:41 CEST] <Daemon404> thats the only time i've sen it
[18:44:42 CEST] <Daemon404> seen*
[18:47:04 CEST] <kurosu> git send-email decided that by itself
[18:47:21 CEST] <kurosu> probably it failed at using the alias file I just created
[18:47:35 CEST] <Daemon404> ah
[18:47:39 CEST] <Daemon404> i always explicitly use --to
[18:48:03 CEST] <kurosu> git send-email --to=ffmpeg out/
[18:48:20 CEST] <kurosu> alias file: "ffmpeg: ffmpeg-devel at ffmpeg.org"
[18:48:28 CEST] <Daemon404> seems like bad behavior to silently fail or act weirdly
[18:49:32 CEST] <kurosu> well, I've just setup that system in order to fix some stuff, but I made that from memory, so I might have failed with that setup, as it works @home
[18:50:39 CEST] <Daemon404> all right-y
[18:53:56 CEST] <kurosu> oh, that might be because I setup aliases for msmtp rather than git send-email
[19:01:33 CEST] <kurosu> and now it seems to have replied to the old patch series mail
[19:01:38 CEST] <kurosu> looks weird here
[19:27:28 CEST] <cone-286> ffmpeg 03Ganesh Ajjanagadde 07master:254c64c574df: cmdutils: silence unused warnings under --disable-swscale, --disable-swresample
[19:30:16 CEST] <kierank> bah, avdev box won't boot
[19:30:21 CEST] <kierank> will have to look on monday
[19:30:40 CEST] <durandal_1707> is there instruction to do paddw + psrlw at once?
[19:32:52 CEST] <jamrial> durandal_1707: Gramner mentioned in a reply to your maskedmerge patch that pmulhrsw (ssse3 instruction) may be used for that
[19:32:55 CEST] <Gramner> durandal_1707: pmulhrsw if the added value is equal to 1<<(shift-1)
[19:33:42 CEST] <Gramner> pmulhrsw is "treat the sixteen-bit words in registers A and B as signed 15-bit fixed-point numbers between 1 and 1 and multiply them together with correct rounding."
[19:34:26 CEST] <Gramner> so only works if you don't need more than 15 bit precision, but that's often enough
[19:42:04 CEST] <durandal_1707> what to use to divide with 255?
[19:42:35 CEST] <Gramner> 128. i have a table i wrote down some time ago, one sec
[19:43:27 CEST] <Gramner> http://pastebin.com/rYJZWXtV
[19:58:14 CEST] <durandal_1707> what to use to negate mm register?
[19:59:00 CEST] <Gramner> pxor dst, dst; psubw dst, src
[20:05:07 CEST] <jamrial> if you're using ssse3, you can probably use psign
[20:06:33 CEST] <durandal_1707> is there instruction to divide by byte number?
[20:07:40 CEST] <jamrial> and for sse2, if you don't have a free reg to clear with pxor as Gramner mentioned, pmullw src, [pw_m1] also works
[20:21:25 CEST] <durandal_1707> I want to divide by 255, is this possible?
[20:35:05 CEST] <BBB> durandal_1707: no
[20:35:21 CEST] <BBB> durandal_1707: you have to convert it to fastdiv (*X>>16), which may not be exactly the same
[20:41:56 CEST] <BBB> kierank: ah crpa
[20:42:05 CEST] <BBB> I was getting used to it already :)
[20:42:36 CEST] <kierank> bit annoying, it pings but port 22 is closed
[20:43:12 CEST] <cone-286> ffmpeg 03Ronald S. Bultje 07master:db7786e8ffa2: vp9: sse2/ssse3/avx 16bpp loopfilter x86 simd.
[20:43:13 CEST] <cone-286> ffmpeg 03Ronald S. Bultje 07master:26ece7a511f8: vp9: 16bpp tm/dc/h/v intra pred simd (mostly sse2) functions.
[20:43:14 CEST] <cone-286> ffmpeg 03Ronald S. Bultje 07master:061b67fb50e2: vp9: 10/12bpp SIMD (sse2/ssse3/avx) for directional intra prediction.
[20:43:16 CEST] <kierank> might have to setup kvm on it
[20:46:06 CEST] <durandal_1707> BBB: what to use for: A < B ? X : Y;
[20:48:11 CEST] <Gramner> in SIMD? maybe pcmpgtw; pand; pandn; por
[20:48:44 CEST] <Gramner> don't think I ever did a conditional SIMD move, so there might be a better way
[20:50:51 CEST] <Gramner> XOP and AVX-512 has vector cmov instructions
[20:59:19 CEST] <jamrial> i wonder if intel NIHd XOP with their relevant AVX2 and AVX-512 intructions, or if it was all already planed when the former was announced 
[20:59:25 CEST] <jamrial> vector cmov, fused multiply-add, the new shift instructions
[20:59:33 CEST] <jamrial> same purpose, different instructions
[21:01:34 CEST] <jamrial> not like it matters much now. XOP is deprecated and will not be featured in Zen
[21:27:43 CEST] <cone-286> ffmpeg 03Paul B Mahol 07master:9762554dd0e9: avfilter/vf_blend: add x86 SIMD for some modes
[21:27:51 CEST] <Gramner> most likely part NIH, part the fact that instruction sets are planned many years before products using them before they're actually release, part the fact that amd and intel doesn't communicate ever (see the FMA3/4 clusterfuck for a concrete example of the latter)
[21:29:08 CEST] <Gramner> also intel most likely don't give a fuck because they know amd has to adapt to them in the end anyway. amd64 was probably the only exception
[21:29:40 CEST] <nevcairiel> amd64 was a different time, too
[21:49:19 CEST] <cone-286> ffmpeg 03Carl Eugen Hoyos 07master:d89820002a7f: lavf/shortendec: Autodetect raw Shorten streams.
[21:55:24 CEST] <BBB> pmovmskb can be helpful for early branch termination
[21:56:14 CEST] <nevcairiel> isnt that one of those insstructions you should avoid
[21:56:15 CEST] <BBB> durandal_1707: but as gramner said, pcmpgtw is typically your friend, and then indeed pand/pandn and por
[21:56:31 CEST] <BBB> durandal_1707: or if its a conditional add, pcmpgtw, pand and then paddw
[22:00:51 CEST] <iive> nevcairiel: i've heard it is quite slow on AMD
[22:01:43 CEST] <cone-286> ffmpeg 03Michael Niedermayer 07master:fd9a528523d0: avfilter/vf_blend: Fix argument types, fix segfault in asm
[22:01:44 CEST] <cone-286> ffmpeg 03Ganesh Ajjanagadde 07master:8d1226e623b2: configure: silence preprocessor noise from dependency generation
[22:27:23 CEST] <cone-286> ffmpeg 03Paul B Mahol 07master:e306e43633a2: avfilter/vf_stereo3d: rewrite in preparation for SIMD
[22:39:11 CEST] <durandal_1707> how to unpack bytes to ints?
[22:39:48 CEST] <nevcairiel> dont think there is a 8->32 expansion, could use two steps 8->16->32
[22:42:29 CEST] <cone-286> ffmpeg 03Carl Eugen Hoyos 07master:32a6d37a6bbd: lavf/mlpdec: Simplify mlp/thd probe function.
[22:44:40 CEST] <Gramner> pmov(s|z)xbd in SSE4
[22:47:34 CEST] <Gramner> what are you doing that requires 32-bit precision with 8-bit inputs?
[22:48:12 CEST] <durandal_1707> anaglyph coefficients
[23:10:50 CEST] <BBB> durandal_1707: if at all possible, try to reduce to 16bit if you can, shuffling is considered the most expensive and unnecessary part in most x86 sim
[23:10:51 CEST] <BBB> d
[23:12:48 CEST] <durandal_1707> how many are there mm registers?
[23:13:27 CEST] <Gramner> 8
[23:14:57 CEST] <Gramner> 8 mmx registers. 8 xmm/ymm registers in x86-32, 16 xmm/ymm registers in x86-64
[23:15:39 CEST] <Gramner> and 32 xmm/ymm/zmm registers with AVX-512 (probably x86-64 only as well)
[23:15:57 CEST] <J_Darnley> did x86-64 not also boost mmx to 16?  (but why would you use them)
[23:16:57 CEST] <durandal_1707> there are 18 anaglyph coefficients
[23:17:18 CEST] <Gramner> no, mmx is considered legacy
[23:17:39 CEST] <durandal_1707> perhaps better to do it in opencl
[23:17:44 CEST] <Gramner> they were afaik considering dropping it in amd64 but ended up keeping it
[23:18:02 CEST] <J_Darnley> ah
[23:18:21 CEST] <kierank> durandal_1707: swscale has simd with more than that
[23:18:22 CEST] <kierank> so it's doable
[23:18:33 CEST] <Gramner> early pre-release 64-bit windows versions also banned the use of mmx iirc
[23:18:36 CEST] <J_Darnley> it was probably a good thing keeping it back then
[23:20:01 CEST] <Gramner> hoestly we would probably have been better off today if they had dropped it, but that would have made a lot of software slower initially when ported to 64-bit which would have made people less likely to upgrade so it's understandable that they kept it
[23:20:40 CEST] <Gramner> the mmx instructions eat up a lot of valuable short opcodes
[23:21:22 CEST] <Gramner> so x86 vector instructions are crazy long. instruction decoding uses tons of energy because of that
[23:22:05 CEST] <cone-286> ffmpeg 03Ganesh Ajjanagadde 07master:c4c389aa146a: avcodec/apedec: fix bug introduced in commit d3e5fbb1406995e07fccbff3ca8c1e24f57a1f7b
[23:22:23 CEST] <Gramner> there's also a whole bunch of useless 1-byte opcodes that nobody uses ever but need to be kept for backwards compatibility
[23:23:41 CEST] <J_Darnley> I just barely remember programming back then.  It was as if the cpuid function didn't exist.  People didn't seem to create software with runtime function selection.
[23:24:12 CEST] <J_Darnley> s/function/instruction/
[23:25:38 CEST] <wm4> haha this webm is generated by lavf
[23:25:41 CEST] <wm4> cascasing failures
[23:25:47 CEST] <wm4> *cascading
[23:29:25 CEST] <J_Darnley> > TestClip\ webm.webm.webm
[23:29:58 CEST] <J_Darnley> is that like file.zip.zip.zip?
[23:31:54 CEST] <wm4> so I expect there will be a patch that specifically fixes demuxing of this file
[23:32:04 CEST] <wm4> while it will continue not to work with other demuxers
[23:32:20 CEST] <nevcairiel> should figure out the muxing problem first
[23:33:50 CEST] <nevcairiel> interestingly seeking works fine in my demuxer
[23:34:45 CEST] <wm4> nevcairiel: I wonder what it does
[23:35:43 CEST] <nevcairiel> worst case, go to the earliest key frame it finds and decode from there
[23:35:56 CEST] <wm4> ah
[23:36:23 CEST] <wm4> that works for me too
[23:36:43 CEST] <wm4> but it's a bit slow
[23:37:16 CEST] <wm4> ah, the seek index is correct
[23:37:19 CEST] <nevcairiel> on my high-end system its noticeable, but still only one second or so when seeking in the last third of the movie
[23:37:41 CEST] <wm4> so the seek index for track 1 has only 1 entry
[23:37:51 CEST] <wm4> all the other seek entries are for the subtitles
[23:38:04 CEST] <wm4> (I wonder why there's no index for the audio track then)
[23:38:26 CEST] <nevcairiel> thats normal
[23:38:44 CEST] <jamrial> because nobody added it to the muxer
[23:38:55 CEST] <nevcairiel> thats also how mkvmerge works, fwiw
[23:39:00 CEST] <nevcairiel> videos of course get one, like normal
[23:39:14 CEST] <nevcairiel> subtitles get an index to be able to find them more easily, since they can be rather sparse
[23:39:18 CEST] <jamrial> yeah, afaik audio seekpoints are added on audio only files
[23:39:26 CEST] <wm4> takes several seconds on my i5 skylake
[23:39:32 CEST] <nevcairiel> this allows features like showing subtitles which started before the seekpoint
[23:39:38 CEST] <wm4> are you sure you're decoding starting from the first packet?
[23:40:08 CEST] <nevcairiel> dunno
[23:40:12 CEST] <nevcairiel> would have to debug into the seeking
[23:40:42 CEST] <nevcairiel> it goes to the closest Cue point, and then forward to the closest key frame
[23:41:10 CEST] <nevcairiel> (closest cue before the requested seek)
[23:42:37 CEST] <wm4> hm, also, what ffplay does (didn't test) suggests it just decides to decode starting from an arbitrary packet?
[23:43:14 CEST] <wm4> can't reproduce though
[23:46:56 CEST] <wm4> actually I can
[23:51:46 CEST] <cone-286> ffmpeg 03Christophe Gisquet 07master:f827a170052e: blockdsp: reindent after parameter removal
[23:51:47 CEST] <cone-286> ffmpeg 03DeHackEd 07master:e06114fed3af: libx264: copy A53 closed captions from source
[00:00:00 CEST] --- Sun Oct  4 2015