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

[burek]

[00:05:12 CEST] <jamrial> atomnuker: if the new mp4 coverart patch is ok then push it
[00:05:49 CEST] <jamrial> that assumes you ran fate and tested it, of course :p
[00:06:39 CEST] <jamrial> atomnuker: although Matthieu Bouron is listed as maintainer. maybe ping him?
[00:10:26 CEST] <cone-496> ffmpeg 03Steve Lhomme 07master:aedbf1640ced: avutil/random_seed: use bcrypt instead of the old wincrypt API
[00:36:03 CEST] <Chloe> wbs: may I PM you?
[00:38:05 CEST] <jamrial> jkqxz: https://0x0.st/sSo0.patch
[00:38:08 CEST] <jamrial> have fun
[00:44:49 CEST] <mkav> Hi, I am currently working on a school project for a portability and optmization course. I am looking to do SIMD optimization for aarch64. Someone in the community pointed me to a function that currently is optimized for x86. The function is called "mdct15_postreindex" in libavcodec/x86/mdct15.asm. Problem is that I have no idea what this function does or how to benchmark it (even after looking at the c equivolent). If anyone has 
[00:45:09 CEST] <atomnuker> mkav: its just doing a lookup
[00:45:25 CEST] <mkav> how I can learn more about this I would appreciate it.
[00:45:57 CEST] <atomnuker> its a lookup, value[index] = other_values[lookup[index]]
[00:46:29 CEST] <atomnuker> benchmark it by including libavutil/timer.h and wrapping the function call with START_TIMER and STOP_TIMER
[00:55:32 CEST] <mkav> Thanks for the help atomnuker! I guess im kinda lost on where this function fits in the program, being that FFmpeg can do so many things. Is it used for all encoding/decoding? 
[00:57:35 CEST] <atomnuker> its used while decoding opus or some aac files
[01:06:14 CEST] <mkav> @atomnuker thanks for the help and sorry if my questions seem silly but I have zero experience with transcoding.. what do you mean by "some" aac files? 
[01:24:25 CEST] <atomnuker> well some aac files use transform sizes that aren't a power of two, but a multiple of 15
[01:24:50 CEST] <atomnuker> those are very rare but we support them
[01:36:54 CEST] <jkqxz> jamrial:  Do we actually want an AV1Packet structure like that?  I thought that the reason for it existing with H.26[45] was to hold the RBSP after emulation prevention, which isn't a concern here.
[01:37:52 CEST] <jkqxz> Also, maybe we need to think about what the policy is wrt "av" prefixing of libav* vs. AV1*.
[01:37:53 CEST] <jamrial> jkqxz: simplifies splitting obus to use in the decoder/s, parser, and cbs
[01:38:28 CEST] <jamrial> as long as we don't prefix a non static function av1, it should be safe
[01:38:34 CEST] <jamrial> but maybe we can use AOM instead
[01:39:59 CEST] <jamrial> that packet structure also simplifies implementing av1 in extract_extradata_bsf
[01:41:09 CEST] <jkqxz> Unrelatedly, do you want to say anything about AMF?
[01:41:15 CEST] <rcombs> FF_AV1?
[01:42:10 CEST] <rcombs> also did that whole "multiple indistinguishable packet formats" thing get resolved
[01:42:49 CEST] <TD-Linux> sorta, only one of the formats is allowed to be packaged
[01:43:26 CEST] <rcombs> what's the other one
[01:44:01 CEST] <jamrial> rcombs: he's talking about struct naming scheme, where AV* is in general used for public structs
[01:44:05 CEST] <jamrial> ff_av1_* is obviously going to be used for shared functions
[01:44:42 CEST] <rcombs> yeah, I know, but if you wanted to disambiguate you could FF-prefix those as well
[01:45:01 CEST] <jamrial> kinda ugly for a struct, IMO
[01:45:34 CEST] <rcombs> wait is this a public or a private struct
[01:46:58 CEST] <jkqxz> jamrial:  Well, it would be nice to avoid having multiple copies of the read/write parsing code.
[01:47:20 CEST] <jamrial> rcombs: private
[01:47:56 CEST] <rcombs> I guess technically it doesn't matter that much either way for structs (since they're not symbols), but FFAV1Packet seems okay to me
[01:48:05 CEST] <jamrial> jkqxz: that's the idea behind writing that packet api. or what do you mean?
[01:49:20 CEST] <jamrial> you mean using the cbs implementation for everything?
[01:49:52 CEST] <jkqxz> Since there aren't any redundant copies it should be doable with a decoder.
[01:50:07 CEST] <jkqxz> Maybe the parser doesn't want the heavier parts of it though.
[01:52:13 CEST] <jamrial> true, unlike h264/hevc we don't have ot deal with legacy crap, so cbs could be used in most modules that require full obu bitstream parsing
[01:53:31 CEST] <jamrial> and yes, the av1 AVCodecParser should be something simple to only set profile, keyframes, pix_fmt, pict_type and maybe frame size
[01:53:46 CEST] <jamrial> so cbs is probably overkill and a lot of overhead on top of the decoder also using it
[01:57:48 CEST] <jkqxz> Hmm, frame size is actually quite hard.  You need to record the sizes of previous frames to determine it.
[02:22:24 CEST] <jamrial> jkqxz: regarding amf, not really. i can test it if you need me to, but hwaccel is not my field
[02:23:22 CEST] <jamrial> one thing i noticed is that he overloaded av_frame_ref by using that name for a local variable, which is kinda ugly but apparently safe
[09:39:26 CEST] <cone-897> ffmpeg 03Paul B Mahol 07master:250792be5e90: avcodec/dxv: add support for "high" quality mode
[10:31:17 CEST] <cone-897> ffmpeg 03Hendrik Leppkes 07master:8df8a9299364: avcodec/aac_ac3_parser: account for data already in the parsing buffer
[11:43:43 CEST] <cone-897> ffmpeg 03Timo Rothenpieler 07master:955fa237f495: avcodec/nvdec: correctly set intra_pic_flag for h264/hevc
[11:44:13 CEST] <Anonrate> Is this an error https://github.com/ffmpeg/ffmpeg/blob/master/compat/windows/makedef#L19 ?
[16:10:41 CEST] <cone-732> ffmpeg 03Paul B Mahol 07master:3e003a985f4b: avfilter/af_headphone: add single hrir multichannel stream mode
[16:11:20 CEST] <wbs> Chloe: feel free to
[16:50:35 CEST] <durandal_1707> michaelni: rgb48 to yuv444p10 looks awfull in swscale
[17:38:15 CEST] <cone-732> ffmpeg 03Alexander Bilyak 07master:9fd11e51882a: configure: fix clang-cl detection
[17:49:05 CEST] <cone-732> ffmpeg 03Mark Thompson 07master:ff1be6c9a694: amfenc: Fail to open if the user-supplied device is not usable
[17:49:06 CEST] <cone-732> ffmpeg 03Mark Thompson 07master:73ed6fa9d77d: amfenc: Do not automatically download/upload unknown hardware input frames
[17:49:07 CEST] <cone-732> ffmpeg 03Alexander Kravchenko 07master:ab7eed13a789: amfenc: Ensure that the software format of hardware frames is valid
[17:49:08 CEST] <cone-732> ffmpeg 03Alexander Kravchenko 07master:2c6ca2b54968: amfenc: Add DXVA2 hardware frame input support
[17:49:09 CEST] <cone-732> ffmpeg 03Mark Thompson 07master:edecd723f3e4: amfenc: Remove spurious initialisations
[18:12:01 CEST] <philipl> BtbN: https://github.com/philipl/nv-codec-headers/commit/03fc16d29fbab95c8de2f752d9c76db53199a818
[18:12:19 CEST] <philipl> Adding additional symbols so that mpv can use nv-codec-headers
[18:14:08 CEST] <BtbN> looks good to me
[18:16:29 CEST] <philipl> Thanks.
[18:16:37 CEST] <BtbN> I'll push it with some other thing I missed
[18:17:23 CEST] <philipl> Ok. Much appreciated.
[18:17:45 CEST] <philipl> And BTW, the auto-mirroring to github must have stopped working. The SDK 8.1 stuff isn't there.
[18:17:55 CEST] <BtbN> There never was auto-mirroring
[18:18:11 CEST] <philipl> "automatic mirror of https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git"
[18:18:14 CEST] <philipl> :-)
[18:18:27 CEST] <BtbN> yes, it's supposed to be one. But nobody seems to know how to set it up
[18:18:46 CEST] <philipl> ah well.
[18:22:44 CEST] <BtbN> it's back in sync now, and all pushed
[18:34:19 CEST] <jamrial> BtbN, philipl: regarding the ffnvenc update from the other day (and now this one), why not just bump the required compile time version in configure instead of wrapping the new lavc nvenc code with preprocessor checks?
[18:34:42 CEST] <BtbN> jamrial, so you can still build it with the old version.
[18:35:11 CEST] <BtbN> The 8.1 SDK puts a quite steep nvidia driver requirement on the resulting binary, and not everyone might want that.
[18:35:40 CEST] <jamrial> so the compile time version affects the required runtime driver version?
[18:35:58 CEST] <BtbN> yes, if you build it with SDK 8.1, it obviously needs a driver that knows about 8.1
[18:36:03 CEST] <BtbN> which is 390 and higher
[18:36:08 CEST] <BtbN> Many distros don't have that
[18:37:10 CEST] <jamrial> bleh, i figured it would gracefully fallback to known features at runtime
[18:37:21 CEST] <BtbN> How would it do that? It changes the API
[18:38:04 CEST] <BtbN> The only thing that's consistent between versions is the size of the strcuts, and the initial field being a version
[19:07:33 CEST] <philipl> BtbN: presumably some of the changes would fail gracefully (eg: maybe the new nvdec fields for hevc would just be ignored by an old driver), but yeah, it's generally a mess to try and fallback cleanly.
[20:51:14 CEST] <durandal_1707> atomnuker: status report!
[20:52:52 CEST] <BtbN> yes, the nvdec part would be compatible. But it's in the same package as nvenc, which wouldn't.
[20:52:58 CEST] <BtbN> so it needs versioning as well
[22:18:42 CEST] <klaxa> mmmmhhh i'm starting to think it would be easier for me and cleaner for the code to extend AVFifoBuffer myself to be thread-safe instead of sprinkling pthread_mutex_(un)lock() around my code
[22:18:52 CEST] <klaxa> got a deadlock and i don't know why :I
[22:30:56 CEST] <klaxa> nvm, found it
[23:20:06 CEST] <jamrial> michaelni: looking at fate, all the kfreebsd slots show something like "test failed comparing 810.927 with 810.932 (abs diff=0.00531006 with EPS=0.005)"
[23:20:20 CEST] <JEEB> 34
[23:20:22 CEST] <jamrial> what seed makes it fail with 0.11 as EPS?
[23:21:13 CEST] <jamrial> of the ten or so runs using different seeds i see, 0.006 looks like would be enough to make it pass
[23:21:43 CEST] <michaelni> the code just prints the first value thats out of range, later values in the same test seem much worse
[23:22:17 CEST] <jamrial> ah, i see
[23:23:09 CEST] <nevcairiel> that seems like a rather high difference even for inaccurate floats
[23:23:22 CEST] <michaelni> seems 0.12 is not enough i just had it fail
[23:23:54 CEST] <durandal_1707> which test is this? silencedetect?
[23:23:59 CEST] <nevcairiel> i also always wonder how that is OS dependent, shouldnt that be a cpu thing
[23:25:03 CEST] <michaelni> test failed comparing 4752.75 with 4752.61 (abs diff=0.137695 with EPS=0.13)
[23:25:04 CEST] <michaelni>    ps_stereo_interpolate_sse3 (aacpsdsp.c:207)
[23:25:04 CEST] <michaelni> test failed comparing 1410.65 with 1410.78 (abs diff=0.131226 with EPS=0.13)
[23:25:04 CEST] <michaelni>    ps_stereo_interpolate_ipdopd_sse3 (aacpsdsp.c:207)
[23:25:18 CEST] <jamrial> durandal_1707: aac stereo_interpolate
[23:27:31 CEST] <jamrial> http://fate.ffmpeg.org/report.cgi?slot=x86_32-ubuntu-mingw32-gcc&time=20180415211618
[23:27:43 CEST] <jamrial> fuck whatever mingw version that slot has
[23:27:53 CEST] <jamrial> first it doesn't define INIT_ONCE, and now it doesn't have bcrypt
[23:28:41 CEST] <jamrial> actually, it does have bcrypt in some form, seeing the configure check passes
[23:28:59 CEST] <jamrial> but it's missing a lot of defines
[23:29:01 CEST] <nevcairiel> some ancient mingw32, we should just call that unsupported and require mingw-w64
[23:29:43 CEST] <jamrial> it is mingw-w64
[23:29:55 CEST] <jamrial> http://fate.ffmpeg.org/report.cgi?slot=x86_64-debian-mingw32-gcc-4.6&time=20180415183234
[23:30:39 CEST] <jamrial> but i guess it's a really, really old version
[23:31:49 CEST] <nevcairiel> gotta hate them for half-assed approach to API support, either add a API fully or don't
[23:32:43 CEST] <jamrial> has bcrypt.h, has BCryptGenRandom prototype, but it's missing all the defines
[23:32:51 CEST] <michaelni> test failed comparing 6329.31 with 6329.01 (abs diff=0.301758 with EPS=0.3)
[23:33:23 CEST] <michaelni> so 0.4 is ATM the smallest that has not failed in brute force testing but i expect it will fail given enough tries
[23:33:44 CEST] <jamrial> michaelni: that's an absurd value. even taking into account this is x86_32 (so x87 floats vs sse), it's way too much
[23:44:32 CEST] <michaelni> jamrial, the implementation of these functions looks numerical unstable (looking at the C code which i guess the asm is based on)
[00:00:00 CEST] --- Mon Apr 16 2018