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

[burek]

[01:25:23 CEST] <BradleyS> is a tarball for 4.2 coming soon, i hope?
[01:43:37 CEST] <BtbN> It'd have to be released first.
[02:48:40 CEST] <Compnn> BradleyS, first is the announce, then the backports, then the tarball and testing, then the release. i think
[04:12:23 CEST] <BradleyS> Compnn: ah, thanks
[14:20:17 CEST] <durandal_1707> kierank: please apply my recent dynaudnorm patch on ML if you can
[14:21:25 CEST] <kierank> Yes when in office
[14:26:10 CEST] <daniel__> Hi everyone ! Does someone of you know how to move "data" from an AVPacket to the corresponding AVFrame(s) (H.264) ? I have a specific bitstream filter, which does some processing and outputs a "decision" and I would like to make use of this "decision" in a vf filter. It looks like the other way around is trivial since bsf filters are applied after vf filter but in this situation I am a bit lost. Thank you in advance :)
[14:27:16 CEST] <J_Darnley> Isn't it a decoder that "moves" data from packets to frames?
[14:28:10 CEST] <J_Darnley> do you mean metadata or side data or similar?
[14:28:29 CEST] <nevcairiel> you probably want side data for that
[14:30:54 CEST] <daniel__> Yes, I would av_packet_add_side_data(...) in my bsf filter but I am not able to make use of this side data in a vf filter.
[14:34:18 CEST] <daniel__> Is there a way to make this side data persistent, so that I can apply the bsf filter to put the side data in the AVPacket and then modify the decoder code to extract the side data from AVPacket(s) and inject it in the AVFrames before filtering ? 
[15:34:32 CEST] <cone-099> ffmpeg 03Andreas Rheinhardt 07master:b56031b992ab: vp3data: Make some arrays unsigned to prevent overflow
[15:34:33 CEST] <cone-099> ffmpeg 03Andreas Rheinhardt 07master:a081a6d20117: avcodec/mpc8huff: Make some arrays unsigned to prevent overflow
[15:34:46 CEST] <durandal_1707> so is there way to do FFT of very long length (2646000) by doing FFT of smaller length?
[15:44:51 CEST] <Lynne> durandal_1707: 2646000 = 16 x 27 x 125 x 49
[15:45:14 CEST] <Lynne> so yeah, if you implement a 27-point, 125-point and a 49-point fft
[15:47:39 CEST] <Lynne> and excluding the 3 and 5-point ones, you'll need a 9-point one, a 25-point one and a 7-point one (7*7)
[15:48:25 CEST] <Lynne> actually no, all you need is a 7 point one
[15:50:53 CEST] <Lynne> thinking again no, you will need a full 27-point, 25-point and a 49-point, since 3x3, 5x5 and 7x7 are not coprimes
[15:52:41 CEST] <durandal_1707> Lynne: https://www.dsprelated.com/showarticle/63.php
[15:53:10 CEST] <durandal_1707> cant i just add some padding and use this ^
[15:56:28 CEST] <Lynne> durandal_1707: this is what tx.c does but less efficiently, the input map is identical but the output map is ommited in favor of a full set of twiddles
[15:57:37 CEST] <Lynne> what filter requires 44100 x 6 fft?
[15:57:52 CEST] <durandal_1707> 44100 x 60
[15:58:08 CEST] <durandal_1707> or any sample_rate * 60
[15:58:37 CEST] <Lynne> yeah, why?
[15:58:54 CEST] <durandal_1707> it is for determining IR frequency response
[15:59:22 CEST] <durandal_1707> for automatic gain and correct display for long lenght IRs
[16:01:30 CEST] <durandal_1707> Lynne: is tx.c limited to max len of 131072 ?
[16:02:10 CEST] <Lynne> no, 131072 * 15 = 1966080
[16:03:33 CEST] <durandal_1707> how hard would be to add support to bigger stuff?
[16:05:11 CEST] <Lynne> to add higher power of two transforms is trivial, add another COSTABLE(X); add DECL_FFT(X, X - 1, X - 2) and add fftX in fft_dispatch[]
[16:06:31 CEST] <durandal_1707> another point two transform is costly, i'm lookiing for using 131072 * X approach
[16:07:52 CEST] <Lynne> to make X larger than 15 you'll need to implement a non-comprime to 3 and 5 transform, like 7 to get 15 * 7
[16:08:19 CEST] <Lynne> 11, 13, 17, 19, etc would work too
[16:09:00 CEST] <durandal_1707> you can do 24 FFT with three 8 FFTs
[16:09:56 CEST] <Lynne> yes, inefficiently, you could implement a hybrid system here too but you're on your own
[16:10:30 CEST] <Lynne> and this case just happens to be this simple since 3 is the lowest factor after 2
[16:11:26 CEST] <durandal_1707> so you not interested in doing 1024 * 131072 FFT in tx.c ?
[16:13:47 CEST] <Lynne> you can do 1024 * 131072 already with a few minor line changes
[16:15:02 CEST] <durandal_1707> i'm interested in that, if that approach is not really slow
[16:15:41 CEST] <Lynne> its a power of two fft, you need effort to make it slow
[16:16:45 CEST] <durandal_1707> just need this complex multiplication .. and summing
[16:17:01 CEST] <Lynne> keep in mind you will end up with a 10, maybe 20, probably more megabyte tx.o, so its not really practical
[16:17:12 CEST] <Lynne> and you can't get away from this really
[16:17:51 CEST] <durandal_1707> i'm talking about approach when only 131072 is used
[16:17:59 CEST] <durandal_1707> no new tables are added to tx.c
[16:18:26 CEST] <Lynne> just write a script that writes COSTABLE(131072 * i), DECL_FFT(X * i, X * i / 2, X * 1 / 4) and fft ## X * i
[16:19:24 CEST] <Lynne> ptwo FFTs require all FFTs down to 4-point in our case
[16:19:44 CEST] <durandal_1707> what fftw uses for such big cases?
[16:20:15 CEST] <Lynne> heap memory requirements will be the same, they still need memory for all twiddles
[16:21:00 CEST] <Lynne> its the code size that will be different, since they probably stop fusing FFTs into functions above some size
[16:22:10 CEST] <Lynne> you could write a recursive function to do that though
[16:23:36 CEST] <Lynne> look at static void fft##n(FFTComplex *z) and just make it recurse until fft_dispatch[N] exists
[16:24:08 CEST] <cone-099> ffmpeg 03Paul B Mahol 07master:73afea3cccbd: avfilter/af_dynaudnorm: add more descriptive aliases for options
[16:24:16 CEST] <Lynne> that way 1024 * 131072 will only be a single 5-odd line function
[16:25:29 CEST] <Lynne> but you will need to make the COSTABLE init for 131072 - 1024 & 131072 be allocated on heap
[16:26:00 CEST] <durandal_1707> yes, those numbers ... how are they calculated?
[16:26:14 CEST] <Lynne> by init_ff_cos_tabs
[16:26:49 CEST] <durandal_1707> and those are this e^i power thingy article mentions?
[16:26:57 CEST] <Lynne> add COSTABLE_MALLOC() which declares the arrays as allocated during runtime and make init_ff_cos_tabs allocate them
[16:27:06 CEST] <Lynne> yes, that's the twiddles
[16:27:31 CEST] <Lynne> but the code in that function only works for ptwo sizes
[16:29:04 CEST] <Lynne> got a paper or something for the filter?
[16:30:32 CEST] <durandal_1707> you mean article or filter feature?
[16:32:24 CEST] <Lynne> yes
[16:32:53 CEST] <durandal_1707> the idea for filter feature is to make impulse response with FFT (instead of current code in liavfilter/af_afir.c)
[16:33:34 CEST] <Lynne> okay, I've just started to benchmark libfftw3f for a 44100x60 transform with SIMD and inplace turned on, the fastest settings
[16:33:39 CEST] <durandal_1707> which is incorrect and deadly slow for big impulse response files
[16:33:44 CEST] <Lynne> its been 30 seconds and its still computing
[16:33:50 CEST] <Lynne> on an i7
[16:34:44 CEST] <durandal_1707> shit, i need time machine to go to far future
[16:36:13 CEST] <Lynne> segfault in my code, trying again, just init, and execute, no filling of arrays or anything
[16:36:35 CEST] <Lynne> 46 seconds for 44100*60
[16:37:45 CEST] <durandal_1707> that is for worst case scenario
[16:37:57 CEST] <durandal_1707> now try for just: 44100*10
[16:38:34 CEST] <Lynne> wait, I forgot I had FFTW_MEASURE, which takes time, trying the simple ESTIMATE version
[16:38:52 CEST] <Lynne> 30 seconds flat -_-
[16:39:28 CEST] <Lynne> trying 1024 * 131072 currently
[16:39:50 CEST] <durandal_1707> if 10*44100 is in <=5 seconds its acceptable
[16:42:19 CEST] <Lynne> 1024 * 131072 is still computing, 4 minutes in or so
[16:42:32 CEST] <durandal_1707> that will never finish
[16:43:35 CEST] <Lynne> yeah, cancelled, trying 44100 * 10
[16:46:03 CEST] <Lynne> a single forward transform takes 9 seconds, just above realtime
[16:46:12 CEST] <Lynne> *below
[16:46:42 CEST] <Lynne> inplace, out of place takes 25 seconds
[16:47:50 CEST] <Lynne> wait, machine is downclocking, will try again in a few minutes
[16:48:02 CEST] <durandal_1707> too hot
[16:48:28 CEST] <durandal_1707> well, i think i will wait for better times instead
[16:50:16 CEST] <durandal_1707> even the results are good, because the gain for IR is calculated only once and used many times after that, but our users are not going to wait that long
[16:51:53 CEST] <Lynne> tried again, no downlocking, 5.8 seconds
[16:53:21 CEST] <Lynne> dunno, I used to not be big fan of filters but often they're just the only pratical solution
[16:55:02 CEST] <Lynne> is there something you can simd there?
[16:56:42 CEST] <durandal_1707> the audio filtering part is already using SIMD a lot, also there are options to control: latency vs speed ratio
[16:57:18 CEST] <durandal_1707> where it for convolution uses by default 8192 window
[16:57:37 CEST] <durandal_1707> for all partitions
[16:58:00 CEST] <durandal_1707> which on my i3 cput gives best speed
[16:58:09 CEST] <durandal_1707> *cpu
[16:58:36 CEST] <durandal_1707> maybe on faster cpu, it can get bigger 16384/32769
[16:59:51 CEST] <durandal_1707> you could write SIMD for af_biquads.c or for af_aiir.c if you feel bored
[17:04:11 CEST] <Lynne> I am occasionally using biquads, and the float version doesn't seem that ba
[17:04:14 CEST] <Lynne> *bad
[17:04:54 CEST] <durandal_1707> use double version always
[17:05:08 CEST] <durandal_1707> we need long long double too
[17:05:43 CEST] <J_Darnley> You sure you don't want to use Google's new Brain format?
[17:07:37 CEST] <durandal_1707> Lynne: i forgot, need double support in tx.c
[17:08:20 CEST] <durandal_1707> with simd for float, and i will then convert af_afir.c (and other FFT filters) to tx.c
[17:09:46 CEST] <Lynne> yeah, ok, I'll try to template that tonight, should be easier than that 8-point fft simd
[17:11:10 CEST] <durandal_1707> Lynne: the simd does not need to be perfect, enough is to be almost as fast as current rdft code
[22:10:51 CEST] <J_Darnley> Wow.  Looks like I was missing a real shit-show today featuring VLC, clickbait scammers, and "security researchers".
[22:24:52 CEST] <J_Darnley> Oh...  Also, a starring roll is played by my favorite "stable = old" character.
[22:54:18 CEST] <jamrial> what was it?
[22:59:39 CEST] <nevcairiel> oh i read some headline to d ay about some claimed security issues in VLC, i didnt actually bother to read the article, i wonder if that was related
[23:35:20 CEST] <ubitux> https://mobile.twitter.com/videolan/status/1153963312981389312
[23:35:33 CEST] <ubitux> jamrial, nevcairiel ^
[23:43:58 CEST] <jamrial> deja vu
[23:45:35 CEST] <nevcairiel> irresponsible security people that just want their name on something that sounds important, you should be able to sue people like that for defamation
[23:55:38 CEST] <Compn> hah welcome to "security" wild wild west
[23:55:50 CEST] <Compn> "we cant change the system its all we have"
[23:55:57 CEST] <Compn> catch 22 
[23:58:18 CEST] <nevcairiel> the sysmte is fine
[23:58:27 CEST] <nevcairiel> its people not following it
[23:59:23 CEST] <J_Darnley> yeah... from what I read: follow the SOP of your organization and you won't have angry twitter messages flying about
[00:00:00 CEST] --- Thu Jul 25 2019