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

[burek]

[00:02:00 CET] <wm4> Chloe: when do you plan to update your list removal patches? (hoping you still want to work on it)
[00:03:25 CET] <ldts> wm4: finally I fixed my sendpatch script (it was parsing the patches and automatically CCing any email addresses it found). v1 is the series I'd like to review (just posted it)
[00:03:39 CET] <Chloe> wm4: ye i will. I just got back to school (but im still ill atm), i reckon next week is when my routine will be normal again and I'll be able to finish it
[00:07:14 CET] <wm4> ldts: heh, ok... to be honest I think mail clients are to be blamed here though
[00:07:22 CET] <wm4> Chloe: great
[00:07:29 CET] <wm4> hoping this gets in before the release
[00:07:46 CET] <wm4> then av_log remains as only observable global state I think
[00:08:14 CET] <wm4> and CPU flags, technically
[02:19:37 CET] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vNmRW
[02:19:37 CET] <KGB> 13FFV1/06master 14a2ef0d0 15Michael Niedermayer: Fix "draft-ietf-cellar-ffv1-00.xml: Line 778: IDREF attribute target references an unknown ID "huffman-coding-mode""
[02:57:10 CET] <KGB> [13FFV1] 15michaelni closed pull request #94: Use log2_{v,h}_chroma_subsample (06master...06chroma_subsample) 02https://git.io/vNvVK
[03:48:00 CET] <klaxa> atomnuker: if you have time, can you test my mkvserver again and see if it works now? i've updated it to git master from jan 3rd
[03:48:26 CET] <klaxa> a few api changes and i'm actually surprised it used to work
[09:30:30 CET] <bogdanC> test
[12:10:19 CET] <atomnuker> klaxa: oh wow, works quite well
[12:10:43 CET] <atomnuker> it seems the slow mode I described previously is the correct one
[12:11:13 CET] <atomnuker> the fast mode doesn't work well, with dropped packets and incorrect timestamps
[12:11:45 CET] <atomnuker> I think you can replicate with an audio-only mkv file and just running the server with it a couple of times
[13:25:26 CET] <klaxa> atomnuker: oh, audio-only was never implemented properly, segments are cut at video i-frames
[13:34:23 CET] <atomnuker> klaxa: ah, makes sense
[13:51:31 CET] <durandal_1707> michaelni: ping
[14:06:43 CET] <jkqxz> Can anyone test overlay_opencl on proprietary Nvidia drivers?
[14:07:31 CET] <jkqxz> <http://ffmpeg.org/pipermail/ffmpeg-user/2018-January/038510.html> seems to imply something going wrong there (usable command line included).
[14:13:01 CET] <BtbN> Does it work on Windows?
[14:15:47 CET] <jkqxz> The report appears to be Linux, but maybe it would act the same on Windows?  I don't know.
[14:18:12 CET] <BtbN> The OpenCL stuff at all I mean
[14:19:38 CET] <jkqxz> Yes, I've tested with both Intel and AMD on Windows.
[14:21:43 CET] <BtbN> I can give it a try on my GTX1050 dev box
[14:28:13 CET] <jkqxz> If you could.  Thank you!
[14:51:07 CET] <BtbN> jkqxz, will take a while, 181 Updates and an new Kernel first
[14:57:48 CET] <Zeranoe> Looks like the recent SDL detection is having some issues: https://gist.githubusercontent.com/anonymous/8567e4dab79020306f53dedb94f8ef23/raw/7f355644aee9b3de54831d5151a1384a6d99ca79/gistfile1.txt
[15:15:30 CET] <raytiley_> Zeranoe: is that why my build recently stopped producing ffplay?
[15:22:52 CET] <jamrial> i'll push a fix in a moment
[15:24:13 CET] <cone-810> ffmpeg 03James Almer 07master:32f85056b3ea: configure: don't use SDL.h in check_func_headers when checking for SDL2
[15:27:54 CET] <Chloe> Does ffmpeg have anything for the structural similarity index measurement? (or does anyone know of any good algorithms for this/better ways to check for image similarity) 
[15:34:27 CET] <jkqxz> The ssim filter?
[15:37:59 CET] <BBB> Chloe: ffmpeg -i file1 -i file2 -lavfi ssim -v info -nostats -f null -
[15:38:10 CET] <BBB> Chloe: you can also use -lavfi psnr or -lavfi libvmaf
[15:38:31 CET] <BBB> Chloe: assuming youre familiar with vmaf
[15:55:29 CET] <cone-810> ffmpeg 03Paul B Mahol 07master:16ba6a8ad141: avformat/wavdec: make fact chunk parsing for w64 more robust
[15:57:17 CET] <jamrial> durandal_1707: INT64_C() is too long and ugly. next time use LL suffix instead
[15:58:22 CET] <durandal_1707> jamrial: i use same code as other lines in code
[15:58:31 CET] <durandal_1707> demuxer
[15:58:39 CET] <jamrial> ah, alright then
[16:25:01 CET] <Chloe> BBB: psnr and vmaf look interesting thanks 
[17:06:54 CET] <chance83> Is there an easy way to search a filter graph for a particular filter AVOption?
[17:38:58 CET] <durandal_1707> so ambisonics never made it?
[17:43:52 CET] <durandal_1707> chance83: ? ffmpeg -h filter=crop
[17:50:03 CET] <chance83> oh I was missing the AV_OPT_SEARCH_CHILDREN flag to av_opt_find
[18:00:31 CET] <atomnuker> durandal_1707: no, you said you were waiting for the channel layour rewrite
[18:01:12 CET] <atomnuker> though we have plenty of bits leftover in channel_layout's uint64_t to signal ambisonics
[18:49:45 CET] <cone-810> ffmpeg 03Paul B Mahol 07master:3c29f68b4db3: avfilter/af_aiir: do not leak memory on failure in convert_zp2tf()
[18:49:46 CET] <cone-810> ffmpeg 03Paul B Mahol 07master:ea25b7b41cb1: doc/filters: fix examples for aiir filter
[19:26:26 CET] <cone-810> ffmpeg 03Paul B Mahol 07master:de5b12c93f85: avfilter/af_aiir: unbreak clipping detection
[20:20:46 CET] <bogdanc> test
[20:30:50 CET] <cone-810> ffmpeg 03Paul B Mahol 07master:de8a1d8d4d0b: avfilter/af_aiir: add polar zeros/poles format variant
[20:33:18 CET] <cone-810> ffmpeg 03Paul B Mahol 07master:6cc44c058396: doc/filters: fix error in aiir options names
[20:47:30 CET] <chance83> where is the best place to contribute patches to avfilters?
[20:48:00 CET] <sfan5> the mailing list?
[20:49:20 CET] <chance83> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel ?
[20:49:31 CET] <jdarnley> yeah, that's the one
[20:49:42 CET] <chance83> awesome, thanks
[20:50:29 CET] <jdarnley> FYI: you should subscribe so your messages don't get held for moderation and so you receive replies
[20:53:24 CET] <chance83> done, thank you sir
[22:27:32 CET] <durandal_1707> all devs are gone, nothing left to push
[22:31:03 CET] <BBB> ?
[22:32:12 CET] <atomnuker> durandal_1707: work on the image fingerprinting thing
[22:38:20 CET] <durandal_1707> atomnuker: there are billion ways to do it wrong
[22:40:41 CET] <rcombs> pick one
[22:44:04 CET] <BtbN> philipl, I opened that IEEE page at work today, and turns out we have free access or something. At least I could just "View Document"
[22:50:45 CET] <BtbN> It does not really have the algorithm though. Only talks about how to make it fast on GPUs
[22:50:56 CET] <BtbN> And I can't find the paper with the actual algorithm it references
[22:51:06 CET] <BtbN> [16] J. Lee, M. Kim, and J. Jeong, An efficient deinterlacing method based
[22:51:06 CET] <BtbN> on new edge-directed interpolation, in Proc. IWAIT 2005, pp. 14.
[22:57:06 CET] <nevcairiel> "new edge-directed interpolation" is what people call "NEDI" around here, might ring more of a bell
[22:57:30 CET] <JEEB> :D
[22:57:52 CET] <BtbN> I'm looking for that specific paper though. Found it: https://www.spiedigitallibrary.org/journals/Optical-Engineering/volume-54/issue-10/103108/Efficient-deinterlacing-method-using-simple-edge-slope-tracing/10.1117/1.OE.54.10.103108.full?SSO=1
[22:59:36 CET] <BtbN> It's really hard to make actual code out of that though
[23:00:18 CET] <atomnuker> so many years spent on trying to make interlaced video look good...
[23:00:28 CET] <nevcairiel> like I said, NEDI has already been implemented, both on CPU and GPU
[23:00:49 CET] <BtbN> I wonder what algorithm the cuvid deinterlacer uses
[23:00:56 CET] <BtbN> it's supposedly just CUDA code
[23:01:21 CET] <JEEB> I think the zimg dude was lately making an optimized NNEDI thing because people were posting benchmarks of a GPGPU thing
[23:01:52 CET] <JEEB> right, https://github.com/sekrit-twc/znedi3
[23:01:55 CET] <nevcairiel> if you happen to use it through dxva interop, it actually uses the fixed function video hardware instead, which results in slightly improved quality (imho anyway), no clue why the pure cuvid mode cannot access that
[23:02:14 CET] <BtbN> Because it's not exactly implemented at all
[23:02:43 CET] <BtbN> Nvidia devs confirmed that, and proposed to just re-implement the algorithm in CUDA, as the one cuvid uses is just running on the CUDA cores anyway
[23:02:57 CET] <JEEB> funky
[23:05:13 CET] <BtbN> nnedi3 is the neural network thing though
[23:05:17 CET] <JEEB> yea
[23:05:17 CET] <BtbN> and google thinks I mean that
[23:05:38 CET] <tmm1> anyone have thoughts on how to cleanly extract a53_cc sidedata in all the h/w mpeg2 and h264 decoders? currently only happens in mpeg12dec.c and h264_slice.c
[23:05:44 CET] <JEEB> oh, so the "NEDI" thing is different than what's with the N-prefix?
[23:06:07 CET] <BtbN> nedi is like nevcairiel said "new edge-directed interpolation"
[23:06:07 CET] <wm4> the usual NNEDI thing is mostly used for scaling these days
[23:06:10 CET] <nevcairiel> its similar-ish but different
[23:06:15 CET] <wm4> having one for deint would be nice too
[23:06:18 CET] <BtbN> nnedi3 is a whole neural network
[23:06:30 CET] <JEEB> yup
[23:06:38 CET] <BtbN> well, I'm planing to implement it as CUDA
[23:06:42 CET] <JEEB> and bases on weights trained by tritical on something ages ago
[23:06:42 CET] <wm4> tmm1: that requires frame reordering, and is the main reason why we do it in the decoder
[23:07:01 CET] <wm4> I think for mpeg2 it might be easy to hack up, but for h264 it gets more complex?
[23:07:07 CET] <nevcairiel> NNEDI is Neural Network Edge-Directed Interpolation, NEDI is sort-of a pre-cursor to that development, but its much simpler to execute
[23:07:24 CET] <wm4> BtbN: why not opencl
[23:07:24 CET] <tmm1> ugh didn't think about re-ordering
[23:07:28 CET] <JEEB> BtbN: I wonder if it would make sense to try and do it like mpv's rendering stuff
[23:07:31 CET] <BtbN> wm4, no interop from CUDA
[23:07:38 CET] <BtbN> And I'm trying to replace the cuvid deinterlacer
[23:07:55 CET] <nevcairiel> tmm1: thats why you should use actual hwaccels instead of stand-alone decoders, you just get that feature automatically
[23:08:00 CET] <JEEB> GLSL/HLSL with GLSL code (and shader compiler used for HLSL)
[23:08:09 CET] <JEEB> since it's image stuff
[23:08:09 CET] <wm4> nevcairiel: no hwaccels on androshit
[23:08:24 CET] <nevcairiel> wm4: too tiny screen to view subtitles as well, so thats fine
[23:08:25 CET] <wm4> actually I'm wondering if "stateless v4l" decoders are just hwaccels
[23:08:32 CET] <wm4> lol
[23:09:11 CET] <BtbN> https://github.com/zachsaw/MPDN_Extensions/tree/master/Extensions/RenderScripts/NEDI here's a hlsl one, and it's even LGPL3
[23:09:29 CET] <JEEB> funky
[23:10:19 CET] <BtbN> https://github.com/zachsaw/MPDN_Extensions/tree/master/Extensions/RenderScripts/OCL_NNEDI3 and nnedi3 in OpenCL oO
[23:10:31 CET] <JEEB> yea NNEDI3 in opencl was not a new thing
[23:10:58 CET] <JEEB> I think zimg person's SIMD version ended up being faster though
[23:11:25 CET] <nevcairiel> NNEDI3 doesn't really work that well in ordinary shaders, so its generally made as compute shaders (ie OCL) more commonly
[23:11:45 CET] <nevcairiel> but the real magic of NNEDI3 is in the weights file, not the ocl code
[23:11:49 CET] <JEEB> yup
[23:12:54 CET] <wm4> and the weights file is fucking big (well, depending on the number of coefficients)
[00:00:00 CET] --- Thu Jan 11 2018