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

[burek]

[00:00:04 CET] <Chloe> atomnuker: his internet connection is very inconsistent
[00:03:24 CET] <atomnuker> he wrote on the ML power was running out and it was snowing a lot
[00:45:27 CET] <Chloe> atomnuker: I mean in general
[00:45:53 CET] <atomnuker> no, I think he just uses different computers or something
[03:28:24 CET] <cone-241> ffmpeg 03James Almer 07master:72bb955625e8: avutil/integer: move the test to the corresponding subdirectory
[03:35:25 CET] <atomnuker> hmm, I wonder if you would need a hashing function for e.g. 32 bit addresses if you have a 64 bit system
[03:35:36 CET] <atomnuker> you have much address space to spare
[03:36:15 CET] <atomnuker> and since linux does lazy alloc you don't have to allocate full 4 gigs worth of data
[03:37:21 CET] <atomnuker> hmm, wouldn't work, if you zero the memory all the data will get allocated
[05:40:19 CET] <cone-241> ffmpeg 03James Almer 07master:7e0dc7210bed: avcodec/vp9_superframe_split: fix memory leak in case of output packet creation failure
[06:25:04 CET] <mistym> Ended up opening an issue for that FILM demuxer problem I ran into. I hit a wall. :b
[12:35:45 CET] <cone-341> ffmpeg 03Paul B Mahol 07master:caef95737e20: avfilter/vf_waveform: add xflat mode
[12:35:46 CET] <cone-341> ffmpeg 03Paul B Mahol 07master:36cf3eb76a72: avfilter/vf_waveform: add orange graticule
[12:49:56 CET] <durandal_1707> atomnuker: if i wanted to do declick audio filter completely in time domain, how would i detect clicks?
[13:26:15 CET] <atomnuker> dunno, I guess through some thresholding to detect
[13:26:44 CET] <atomnuker> there should be some research on declicking records
[13:52:10 CET] <Compn> there are some open source depop and declick filters no doubt
[14:05:26 CET] <durandal_1707> Compn: no shit, Sherlock
[15:31:57 CET] <durandal_1707> i found gtk-wave-cleaner, and this software found clicks there where everything is fine
[15:32:07 CET] <durandal_1707> so this is PoS
[16:09:35 CET] <durandal_1707> atomnuker: i found perfect code with AGPL license
[16:10:07 CET] <atomnuker> well that sucks
[17:12:36 CET] <wm4> jamrial: what are you trying to achieve with all those buffer changes anyway? optimization?
[17:17:50 CET] <philipl> durandal_1707: set up a shell company to run it as a service which you can be a client for :-)
[17:20:17 CET] <jamrial> wm4: you mean the dynamic buffer patch?
[17:21:42 CET] <durandal_1707> philipl: why?
[17:24:11 CET] <wm4> jamrial: yes, and all those other patches
[17:24:51 CET] <jamrial> well, it started by trying to get h265_parse to extract nal units using refcounted buffers so anything using it can skip an alloc+memcpy if they need to do something more complex than reading the getbitcontext and then forget about it
[17:25:44 CET] <jamrial> for which i wrote the fast_alloc function, but it wasn't optimal so i followed your suggestion to extend the buffer pool API to support non fixed sized buffers, to use that instead
[17:26:30 CET] <jamrial> the bitstream patches are unrelated but also about performance. less data copy and packet alloc, more refs
[17:35:54 CET] <jamrial> a7a8320c4f for example is a no brainer. the null bsf is used by decode.c unconditionally (that still could be changed, though), which before said commit was doing a pointless roundtrip of alloc, two ref moving, then free
[17:38:05 CET] <jamrial> so with that we saved one alloc and free for every packet decoded by every decoder, except vp9 and some hw h264/hevc decoders
[18:33:30 CET] <philipl> durandal_1707: AGPL joke.
[20:09:42 CET] <cone-341> ffmpeg 03Bela Bodecs 07master:1b45e6db22d9: avformat/unix: fix handling of EOF in case of SOCK_STREAM.
[21:18:30 CET] <durandal_1707> atomnuker: this click detection and samples interpolation in time domain is like alien tech for me
[21:19:17 CET] <durandal_1707> also it is not real time in most cases, 3x at best
[22:54:06 CET] <atomnuker> yeah, that's to be expected, I suppose if it does some autocorrelation
[23:02:03 CET] <durandal_1707> and auto regression
[23:40:22 CET] <durandal_1707> for some strange reason it uses wrong window function, introducing additional clicks in audio and than calls same algorithm again
[23:40:45 CET] <nevcairiel> easier to detect clicks if you make the audio have more
[00:00:00 CET] --- Thu Mar 22 2018