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

[burek]

[00:47:18 CEST] <cone-799> ffmpeg 03Rostislav Pehlivanov 07master:a72d0fb97336: mdct15: simplify the fft15 x86 SIMD
[00:47:19 CEST] <cone-799> ffmpeg 03Rostislav Pehlivanov 07master:29eb1c51d735: mdct15: simplify x86 exptab permutation
[01:23:12 CEST] <JEEB> hah, so we really hit the case where zvbi was doing something wrong :(
[01:31:23 CEST] <tmm1> i guess so, looks like it happens even in bitmap mode
[01:34:11 CEST] <kierank> ask funman about this problem
[01:34:19 CEST] <kierank> we had it as well, iirc an ffmpeg implementation problem
[01:35:17 CEST] <kierank> and vlc uses libzvbi
[01:37:52 CEST] <kierank> tmm1: vlc looks fine with that sample
[01:38:56 CEST] <kierank> depending on where you seek it looks wrong actually
[01:39:23 CEST] <kierank> so maybe you found a rare zvbi bug
[01:41:03 CEST] <tmm1> i was just playing normally from start
[01:42:22 CEST] <tmm1> vlc here has the same issue
[01:42:54 CEST] <tmm1> there are two spots in the video where top line doesn't disappear while the bottom line changes
[03:38:23 CEST] <atomnuker> can I use a prefix without an underscore for the lavu fft move?
[03:38:35 CEST] <atomnuker> as in avfft_init()
[03:39:02 CEST] <atomnuker> since av_fft_ is already taken by the fft in lavc
[03:55:29 CEST] <jamrial> no, avutil_fft() maybe
[03:56:27 CEST] <jamrial> although that's currently used only for informative avutil related functions
[03:57:20 CEST] <jamrial> didn't we move functions between libs at some point, retaining the namespace?
[04:01:14 CEST] <atomnuker> the thing is the functions themselves need to change to accomodate non-ptwo transforms so the arguments change too
[04:01:41 CEST] <atomnuker> nevcairiel told me its only possible if the ABI doesn't change
[04:02:35 CEST] <atomnuker> btw does msvc support complex.h?
[04:03:28 CEST] <atomnuker> seems not, I'll write an emulation layer
[04:15:23 CEST] <jamrial> ah, in that case yeah, can't be the same
[04:21:41 CEST] <atomnuker> btw just curious, what did we move between libs?
[04:34:11 CEST] <jamrial> avframe was one thing, i recall
[09:33:01 CEST] Action: JEEB puts his safety glasses back on, gets to looking at how the MPEG-TS demuxer or framework could be made to wait for PCR
[10:00:38 CEST] <cone-157> ffmpeg 03Gyan Doshi 07master:0683ad709b0e: avformat/segafilmenc - set keyframe bit correctly
[10:29:15 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:f1248b779585: lavfi/nlmeans: random code shuffling to help compiler
[10:29:16 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:26f02c51ce97: lavfi/nlmeans: add SIMD-friendly assumptions for compute_safe_ssd_integral_image
[10:29:17 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:5ba14f4f1a5e: lavfi/nlmeans: use ptrdiff_t for linesizes
[10:29:18 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:5a71bce3713c: lavfi/nlmeans: add AArch64 SIMD for compute_safe_ssd_integral_image
[10:29:19 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:f679711c1b51: checkasm: add vf_nlmeans test for ssd_integral_image
[10:29:20 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:43d16aef6395: lavfi/nlmeans: make compute_safe_ssd_integral_image_c faster
[10:29:21 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:667503ef6879: lavfi/nlmeans: switch from double to float
[10:29:22 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:34e1e53e2885: lavfi/nlmeans: move final weighted averaging out of nlmeans_plane
[10:29:23 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:de956198a9ec: lavfi/nlmeans: reorder memory accesses in get_integral_patch_value
[10:29:24 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:4278f79ef610: lavfi/nlmeans: use unsigned for the integral patch value
[10:29:25 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:e6114d21ac00: lavfi/nlmeans: inline integral patch value function
[10:30:13 CEST] <ubitux> durandal_1707: farindk version seems to use a much smaller research window
[10:30:24 CEST] <ubitux> assuming it's the range parameter
[10:30:47 CEST] <ubitux> try r=3 with ff nlmeans
[10:31:01 CEST] <ubitux> it will be much faster that way
[10:31:22 CEST] <ubitux> the scale of the strength doesn't look the same too
[10:31:56 CEST] <ubitux> it may have an impact
[10:33:40 CEST] <ubitux> it seems to have temporal enabled, if you're making comparisons you may want to disable it on his side
[10:33:55 CEST] <ubitux> (or add it in ffmpeg)
[10:34:16 CEST] <durandal_1707> ubitux: how temporal works? it also searches prev/next frames?
[10:34:24 CEST] <ubitux> yeah
[10:34:39 CEST] <ubitux> it looks up for blocks not only in the surrounding but also in the previous frames
[10:35:12 CEST] <ubitux> (and thus it's making the filter slower)
[10:35:29 CEST] <ubitux> it's similar to enlarging the research window
[10:35:35 CEST] <ubitux> it has a large impact on performances
[10:58:05 CEST] <durandal_1707> ubitux: what you think about fftdnoiz ?
[10:58:46 CEST] <ubitux> dunno, does it just blur like dctdnoiz?
[11:07:12 CEST] <durandal_1707> ubitux: only if you set very high sigma (and than you can expect worse thing than just blurring), otherwise it reduces noise
[11:08:55 CEST] <durandal_1707> also doing only 2d is bad, i already added 3d operation and >16 bit support
[11:09:04 CEST] <durandal_1707> * >8
[11:45:09 CEST] <cone-157> ffmpeg 03Martin Vignali 07master:6ebc71847e21: fate/hapenc : remove tests due to inconsistent result
[11:53:59 CEST] <ubitux> durandal_1707: what's the 3rd dimension? other frames?
[11:54:43 CEST] <ubitux> how slow/fast is it? did you compare the results with other denoisers? there are many relatively advanced denoisers on ipol
[12:08:56 CEST] <durandal_1707> ubitux: they are all extremly slow
[12:09:27 CEST] <durandal_1707> ubitux: 3d is prev or next or both
[12:45:22 CEST] <durandal_1707> imho nlmeans is very strong even at 1
[12:48:18 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:8d6354aa8284: lavfi/nlmeans: use AV_CEIL_RSHIFT instead of deprecated FF_CEIL_RSHIFT
[12:48:19 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:1eb4e731fc44: lavfi/swaprect: use AV_CEIL_RSHIFT instead of deprecated FF_CEIL_RSHIFT
[12:48:20 CEST] <cone-157> ffmpeg 03Clément BSsch 07master:6876a6336893: lavc/cfhd: use AV_CEIL_RSHIFT instead of deprecated FF_CEIL_RSHIFT
[12:48:46 CEST] <ubitux> durandal_1707: even with a small research window?
[12:49:30 CEST] <ubitux> if you reduce the research window it will average with less stuff around
[12:50:26 CEST] <durandal_1707> yes
[12:53:19 CEST] <ubitux> do you have a sample?
[12:54:53 CEST] <durandal_1707> not needed, its fine with lower r
[12:55:08 CEST] <ubitux> ok :)
[12:55:27 CEST] <durandal_1707> perhaps sigma should be scaled with p & r ?
[12:55:42 CEST] <ubitux> yeah, see the todo
[12:56:10 CEST] <ubitux> iirc that paper section is related to this
[12:56:20 CEST] <ubitux> but i haven't bothered looking at it yet
[13:09:40 CEST] <durandal_1707> you cant denoise very bad vhs tapes with only spatial filtering
[13:11:19 CEST] <ubitux> feel free to add temporal support :)
[13:30:31 CEST] <BtbN> Can one entry in APIchanges be used for multiple commits? Adding another one for just that one little change seems overkill.
[13:31:53 CEST] <ubitux> assuming you bump only once it should be fine
[13:32:28 CEST] <ubitux> the APIchanges entries are associated with a new version + a header (sometimes several?)
[13:32:35 CEST] <durandal_1707> anyone have unprocessed noisy clips?
[13:32:38 CEST] <BtbN> The second change is a micro bump, first change minor bump
[13:32:56 CEST] <nevcairiel> if its somewhat close in time, then it should be fine
[13:33:05 CEST] <BtbN> it will be in one batch of patches
[13:34:48 CEST] <ubitux> durandal_1707: fate-samples/smjpeg/scenwin.mjpg?
[13:34:56 CEST] <durandal_1707> please no
[13:35:08 CEST] <ubitux> :D
[13:37:44 CEST] <ubitux> if you're looking for picture, i like to test with http://b.pkh.me/p_009.png
[13:37:53 CEST] <ubitux> but i guess you want to try the temporal stuff
[13:37:58 CEST] <durandal_1707> ubitux: yes
[13:38:37 CEST] <durandal_1707> i could experiment with noise filter, but that one does not emulate vhs noise
[13:39:07 CEST] <ubitux> i may have shitty anime rip around
[13:39:13 CEST] <ubitux> but that's a particular type of content
[13:39:33 CEST] <ubitux> i have shitty vhs rip too, but you're going to get more annoyed at the blocking stuff than the noise
[15:48:53 CEST] <BtbN> Is Thunderbird just confused or did I actually send that series 5 times?
[15:49:26 CEST] <BtbN> seems like it's just Thunderbird
[15:49:41 CEST] <JEEB> I only see a set in gmail's mobile interface
[15:50:01 CEST] <BtbN> The E-Mails came out of order, and Thunderbird attached the whole thread to every out of order mail it got
[15:50:05 CEST] <BtbN> So I had it 5 times
[15:50:14 CEST] <BtbN> a restart fixed it
[16:27:06 CEST] <BtbN> oh nice, Windows 10 1803 now lets you define the default audio input/output device per application
[16:28:05 CEST] <JEEB> nice
[16:28:32 CEST] <BtbN> Only in one of their horrible "modern" UI control panel apps though
[16:29:09 CEST] <BtbN> It still baffles me how any ui designer can think that it's a good idea to replace a number-input-spinner with a number and up/down buttons on top of it, which inc/dec the number one step per click
[16:29:18 CEST] <BtbN> with no other way to input a number in the range from 0 to 100
[17:07:21 CEST] <jamrial> nevcairiel: can you test my patch? msvc has been broken for a couple days now
[17:08:44 CEST] <jamrial> maybe we should move the access wrapper from lavf os_support.h to lavu file_open.c and make it public, or at least avpriv
[17:15:01 CEST] <nevcairiel> that wouldnt fix anything anyway
[17:15:13 CEST] <nevcairiel> it only deals with unicode paths, not the lack of those constants
[17:17:43 CEST] <jamrial> the constants can be defined as well
[17:18:34 CEST] <nevcairiel> any file access should really use avio, though
[17:18:53 CEST] <ubitux> jamrial: should i send a patch to revert the android/perf thing?
[17:19:09 CEST] <jamrial> ubitux: why?
[17:19:19 CEST] <ubitux> because it's not needed
[17:19:24 CEST] <jamrial> oh, you mean my "fix"
[17:19:25 CEST] <nevcairiel> in fact, it even uses avio
[17:19:25 CEST] <jamrial> sure
[17:19:28 CEST] <nevcairiel> except for that one call
[17:19:36 CEST] <nevcairiel> so why not add that if its needed
[17:19:44 CEST] <jamrial> nevcairiel: mention that to the author in the thread, then
[17:19:54 CEST] <jamrial> but until he gets around to do that, we should at least make msvc compile again
[17:21:25 CEST] <nevcairiel> in fact
[17:21:30 CEST] <nevcairiel> we even have an avio call for that
[17:21:40 CEST] <nevcairiel> avio_check(url, AVIO_FLAG_READ)
[17:27:10 CEST] <wm4> wtf
[17:27:32 CEST] <wm4> does that also open and close a http connection for http protocols
[17:27:41 CEST] <nevcairiel> send a patch for that to the ML
[17:27:42 CEST] <wm4> what does it do for udp
[17:27:52 CEST] <nevcairiel> no clue, i only checked its file implementation
[17:28:30 CEST] <nevcairiel> apparently it does simply try to open it w hen there is no dedicated checking function
[17:43:56 CEST] <nevcairiel> hrm the .rm demuxer bug is the only one that remains in the latest msvc version, maybe i should look into whats causing that already
[17:45:04 CEST] <wm4> wow so libavfilter depends on libavformat
[17:45:15 CEST] <nevcairiel> better then re-implementing file access
[17:45:21 CEST] <wm4> fopen is hard
[17:45:22 CEST] <nevcairiel> also thats not the first
[17:45:31 CEST] <kierank> wm4: been like that for a while, no?
[17:45:34 CEST] <nevcairiel> the movie src filter did that since forever
[17:45:41 CEST] <wm4> kierank: apparently
[17:45:43 CEST] <jamrial> wm4: there are like ten filters using lavf stuff
[17:46:05 CEST] <wm4> shitty mudball of bloat
[17:46:12 CEST] <jamrial> movie/amovie, for example
[17:49:49 CEST] <durandal_1707> wm4: what you said?
[18:03:11 CEST] <cone-517> ffmpeg 03Hendrik Leppkes 07master:8007a8636393: lavfi/vf_srcnn: use avio_check instead of access
[18:07:48 CEST] <durandal_1707> ubitux: i cant get nlmeans to be stable, if i change research window i need to change patch size and sigma to get good results, otherwise strange artifacts appear
[18:11:43 CEST] <ubitux> yeah, but i think that's how the algorithm is supposed to be designed
[18:12:05 CEST] <durandal_1707> this usually happens with very strong noise, very noiceable ringing artifacts
[18:18:35 CEST] <nevcairiel> how does one pass an absolute windows paths to lavfi parameters (it contains a colon) ? no amount of quoting made it stop parsing it, and i dont know if there is other escaping magic
[18:18:50 CEST] <nevcairiel> (from cli)
[18:19:00 CEST] <durandal_1707> \\ ?
[18:22:07 CEST] <nevcairiel> apparently quoting and escaping works
[18:22:23 CEST] <nevcairiel> only one of thsoe doesnt
[18:23:09 CEST] <nevcairiel> probably one for the shell and one for ffmpeg?
[18:32:58 CEST] <philipl> BtbN, wm4: I took a quick look at the videotoolbox code and I think it just wastes memory in the way that BtbN is trying to avoid.
[18:33:34 CEST] <philipl> It uses the hwaccel alloc_frame callback to allocate frames itself, and not get them from the hw_frame_ctx's pool, but the pool is just a normal pool.
[18:33:50 CEST] <philipl> Maybe that technique would be sufficient here?
[18:33:59 CEST] <BtbN> philipl, the videoboolbox hwframesctx does not have an internal AVBufferPool
[18:34:01 CEST] <BtbN> but it uses it
[18:34:08 CEST] <BtbN> so it relies on the pool being supplied externally
[18:36:16 CEST] <wm4> wut
[18:36:28 CEST] <wm4> philipl: what memory does it waste?
[18:36:31 CEST] <philipl> BtbN: does it use it? It does alloc_frame and then those can work with the hw_frames_ctx but it doesn't use the ctx pool
[18:36:47 CEST] <BtbN> the hwframes_ctx uses it
[18:36:54 CEST] <philipl> wm4: Sorry, it doesn't, because it doesn't request anything from the pool.
[18:37:29 CEST] <wm4> videotoolbox literally just uses the hwframes stuff to make it play nicely with the libavcodec infrastructure
[18:37:46 CEST] <philipl> I think this works because you give videotoolbox the buffer to fill, and so alloc_frame is fine.
[18:37:52 CEST] <wm4> it could just return blank AVFrames with only the videotoolbox hw reference (like it used to)
[18:38:02 CEST] <philipl> for nvdec, we can't do that, so the situation is different.
[18:38:10 CEST] <wm4> well then I don't get it
[18:38:26 CEST] <philipl> Don't get what? This is to your question of why can't it be done the way videotoolbox does it.
[18:39:45 CEST] <BtbN> It can't be done the videotoolbox way. But it can be done a way that doesn't need any API changes
[18:40:49 CEST] <philipl> BtbN: as in what your patch series does?
[18:41:15 CEST] <BtbN> Yes. The hwframesctx stuff will use an externally supplied BufferPool, if it's set before init is called
[18:42:11 CEST] <philipl> BtbN: Sorry - losing track. Your patch series has the flag. You want to use a dummy buffer pool instead?
[18:42:25 CEST] <BtbN> so I'll just pass a custom buffer pool that... does nothing
[18:42:50 CEST] <philipl> OK. We discussed that yesterday. :-)
[18:43:05 CEST] <BtbN> I just missed you can pass in an external buffer pool
[18:43:38 CEST] <philipl> Alright. And if an API user passes their own hw_frames_ctx with a real pool, it wastes memory but works correctly.
[18:44:31 CEST] <BtbN> yeah
[18:44:38 CEST] <philipl> mpv only passes a device_ctx, so that's fine.
[18:45:51 CEST] <BtbN> What I'm a bit confused about is: Do I need to free the buffer pool myself, or does the hwframes ctx take ownership?
[18:46:13 CEST] <wm4> why does it need a buffer pool?
[18:46:21 CEST] <BtbN> To allocate the frames?!
[18:46:37 CEST] <wm4> but the buffer pool contains dummy objects?
[18:46:40 CEST] <wm4> so it allocates nothing
[18:46:46 CEST] <BtbN> ...
[18:46:53 CEST] <wm4> indeed
[18:46:55 CEST] <BtbN> No, a normal pool does not allocate dummies
[18:47:09 CEST] <BtbN> I want it to allocate dummies, so it doesn't waste memory. That's the whole point.
[18:47:32 CEST] <wm4> ?????
[18:47:41 CEST] <wm4> why allocate dummies if you could just allocate nothing
[18:47:50 CEST] <wm4> that's why I mentioned videotoolbox
[18:48:06 CEST] <BtbN> I have no idea what you're confused about.
[18:48:18 CEST] <BtbN> videotoolbox frames work entirely diffrent
[18:49:26 CEST] <philipl> videotoolbox can allocate frames on demand. nvdec uses a fixed pool so it has to be modelled.
[18:49:45 CEST] <BtbN> cuda frames just normally contain actual video memory
[18:49:50 CEST] <BtbN> not just a mapping or handle
[18:50:24 CEST] <wm4> so it's literally only about passing through initial_pool_size in a way that makes the hwaccel framework happy? or what
[18:50:40 CEST] <philipl> BtbN: as for freeing - the code says it only frees an internal pool, not an external one.
[18:50:56 CEST] <philipl> And I remember fiddling with this when I did my cuda array experiment way back when.
[18:51:01 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/hwcontext.h;h=f5a4b623877477c0d778bea1ab051be074fe09d5;hb=HEAD#l176 this is weird. It claims "The pool will be freed strictly before this struct's free() callback is invoked."
[18:51:14 CEST] <BtbN> But I don't see it ever freeing it
[18:51:20 CEST] <philipl> Yeah. Only the internal pool
[18:51:28 CEST] <BtbN> So the documentation is wrong?
[18:51:37 CEST] <BtbN> So I guess I just add a free callback, and uninit my pool there
[18:51:50 CEST] <philipl> I guess. Presumably you can't make it free it now without breaking de-facto API semantics.
[18:52:07 CEST] <BtbN> well, the free callback seems to exist for that purpose
[18:55:54 CEST] <philipl> yeah
[19:00:48 CEST] <philipl> BtbN: I'll wait for new patch set.
[19:16:17 CEST] <durandal_1707> ubitux: are you gonna add >8 bit depth support to nlmeans? do you know what in code assumes 8 bit depth?
[19:24:27 CEST] <BtbN> philipl, https://github.com/BtbN/FFmpeg/commit/72e43650b67aef40bec6432b8416c17e813faa01
[19:27:09 CEST] <nevcairiel> BtbN: frames basically need to be able to stay alive even after the decoder is closed or re-created for the full AVFrame lifetime semantics to be valid, does this fullfill this?
[19:27:22 CEST] <BtbN> yes
[19:27:32 CEST] <BtbN> That's the point of all the buffer_refs it carries around
[19:27:58 CEST] <BtbN> it keeps a ref for the cuvid picture index, so it doesn't get re-used, and it carries a ref to the decoder itself, so it doesn't get freed
[19:42:39 CEST] <llogan> durandal_1707: i have some noisy VHS samples (as DV) if you need any.
[19:47:05 CEST] <durandal_1707> llogan: first send me single representative frame, so you do not need to pointlessly upload one
[19:50:30 CEST] <ubitux> durandal_1707: i didn't plan anything on nlmeans so far, but 10-bit might be tricky
[19:50:44 CEST] <ubitux> because accumulated diff is stored on u32
[19:50:51 CEST] <llogan> durandal_1707: ok. i will try to get one to you within an hour unless work gets in way
[19:50:56 CEST] <ubitux> on large image, i believe it can already be an issue
[19:51:20 CEST] <ubitux> you can switch to u64 but then you have to rewrite some code (+asm)
[19:51:37 CEST] <ubitux> also, it will hurt speed so you want to keep the u32 version for when appropriate
[20:26:11 CEST] <llogan> durandal_1707: found them. do you want a typical VHS video or one with extra noise?
[20:44:50 CEST] <llogan> durandal_1707: https://0x0.st/sjAi.png
[20:45:01 CEST] <llogan> found a good one for you
[20:57:31 CEST] <durandal_1707> llogan: upload video with few frames somewhere, do not transcode
[21:03:58 CEST] <durandal_1707> ubitux: well, one could write .c file as template?
[21:04:45 CEST] <ubitux> yeah i don't think it's impossible at all
[21:06:16 CEST] <ubitux> i wouldn't say it's the priority for the filter, but you can do that ofc
[21:06:33 CEST] <ubitux> x86 SIMD, temporal support, and smart parameters would be nice i think
[21:13:01 CEST] <durandal_1707> ubitux: what about bm3d filter?
[21:16:46 CEST] <llogan> durandal_1707: https://0x0.st/sjAZ.dv
[21:18:53 CEST] <philipl> BtbN: Change looks good to me.
[21:19:31 CEST] <philipl> Assuming API users are required to manage decoders through buffer refs and not direct allocation...
[21:20:36 CEST] <BtbN> hm?
[21:20:49 CEST] <BtbN> that's how frames work?
[21:20:58 CEST] <philipl> I meant the decoder instance itself.
[21:21:23 CEST] <BtbN> not sure what you mean
[21:21:26 CEST] <philipl> You used a ref to keep the decoder alive as long as the frame is alive.
[21:22:24 CEST] <BtbN> yes, frames carry a bunch of refs around anyway
[21:22:56 CEST] <durandal_1707> llogan: thanks
[21:25:31 CEST] <philipl> BtbN: yeah. no concern - just needed to get this straight in my head
[21:37:36 CEST] <durandal_1707> ubitux: can you denoise this: https://0x0.st/sjAm.nut without blurring?
[21:52:03 CEST] <ubitux> durandal_1707: that's subjective but nlmeans=s=6:r=5 doesn't look that bad
[21:53:16 CEST] <ubitux> nice sample btw
[21:53:20 CEST] <ubitux> (source?)
[22:06:53 CEST] <durandal11707> ubitux: from doom9, its raw float gray, but i converted it with patch to libavutil and geq to gray8
[22:08:06 CEST] <durandal11707> thing is, i want to get background to be solid gray as possible with nlmeans
[22:09:01 CEST] <durandal11707> fftdnoiz have no such problems, but its algo is >20 years old
[22:11:50 CEST] <durandal11707> ubitux: https://forum.doom9.org/showthread.php?t=174249&page=2
[22:12:40 CEST] <durandal11707> their nlmeans/bm3d can do it
[22:16:56 CEST] <durandal11707> perhaps adding temporal part will make this possible?
[22:20:36 CEST] <ubitux> yeah temporal may help here
[22:22:25 CEST] <durandal11707> ubitux: but even only 2d fftdnoiz can do it 95%
[22:29:23 CEST] <ubitux> i don't know, KNLMeansCL(clip, 6, 32, 3, 4.0)
[22:29:28 CEST] <ubitux> what are the params here?
[22:29:54 CEST] <ubitux> nb frames, research window, patch size, strength?
[22:30:49 CEST] <ubitux> we probably want to add temporal support to ff nlmeans so we can actually compare with other implementations
[22:30:56 CEST] <ubitux> it seems most of them have it
[22:33:29 CEST] <ubitux> 32 for the research windows looks huge though
[22:33:37 CEST] <ubitux> it's probably extremelly slow
[22:33:45 CEST] <ubitux> especially with 6 frames
[22:33:53 CEST] <ubitux> assuming i guessed the parameters right
[23:07:42 CEST] <ubitux> durandal11707: i guess i'll try to implement the temporal support
[23:20:54 CEST] <durandal11707> ubitux: nlmeans=r=15:s=5 did it
[23:21:18 CEST] <ubitux> durandal11707: i'm not used to the new lavfi api; any modern filter i could use for reference caching frames + sending some with delay?
[23:22:23 CEST] <ubitux> cool, ok for the settings
[23:24:16 CEST] <durandal11707> ubitux: atadenoise, tmix(vf_mix.c) for big temporal radius
[23:24:24 CEST] <ubitux> thanks
[23:25:06 CEST] <durandal11707> you just keep frames in queue, can be simple array
[23:25:32 CEST] <ubitux> yeah i was wondering what was the purpose of this FFBufQueue
[23:28:25 CEST] <durandal11707> could also add sad in place of ssd
[23:29:11 CEST] <ubitux> yeah, it would prevent some overflow
[23:29:22 CEST] <ubitux> but the formula change
[23:29:27 CEST] <ubitux> i'm not exactly sure how
[23:33:24 CEST] <durandal11707> ? sad just takes absolute differences
[23:33:48 CEST] <ubitux> yeah but it has an impact on how you interpret it
[23:34:20 CEST] <ubitux> the scaling interpretation is typically different
[23:34:28 CEST] <ubitux> the weighting of the patch changes
[23:35:03 CEST] <ubitux> the f(x)=x² curve is not the same as f(x)=|x|, so the exponential and stuff change
[23:35:11 CEST] <ubitux> i'm not sure you can get the exact same result
[23:35:26 CEST] <ubitux> but i'm not a math fluent person
[23:35:30 CEST] <ubitux> (far from it)
[23:35:52 CEST] <ubitux> so i kept the original algorithm, even though sad was mentioned
[23:42:58 CEST] <ubitux> maybe i just need pdiff_scale = 1./h
[23:43:04 CEST] <ubitux> instead of 1./h²
[23:43:21 CEST] <ubitux> (according to the formula @ http://avisynth.nl/index.php/TNLMeans)
[23:53:40 CEST] <klaxa> phew, after some days of reading and thinking and coding, i at least managed to more or less decouple the specific network implementation from the server logic
[23:53:59 CEST] <klaxa> still buggy, but first tests work
[23:59:56 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:5c705134183d: avformat/mxfenc: Correct KAG alignment of preface
[23:59:56 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:3ba1bbb4f992: avformat/mxfenc: Bump minor versions for S377-1-2009
[23:59:56 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:86c92509231f: avformat/mxfenc: Add Product Version, Toolkit version and Platform
[23:59:56 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:1b6c89ca8db2: avformat/mxfenc: Add object model version
[23:59:56 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:77cbe698cd91: avformat/mxfenc: Fix stored width
[23:59:56 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:2bee43b67dc5: avformat/mxfenc: Add vertical subsampling support
[23:59:56 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:6d0339096e10: avformat/mxfenc: add white/black ref /color range
[23:59:57 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:1246754c80a4: avformat/mxfenc: Add Padding Bits
[23:59:58 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:530ac1e50bd7: avformat/mxfenc: Write Audio Ref Level for D10
[23:59:59 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:c35ca7e01c88: avformat/mxfenc: Add Stored F2 Offset / Image Start/End Offset for D10
[00:00:00 CEST] --- Wed May  9 2018