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

[burek]

[00:07:05 CET] <kierank> the headers that the parser uses as far as I can tell don't need vlc codes
[00:44:38 CET] <michaelni> the parser could call code that calls mpeg4_decode_sprite_trajectory() i think
[00:45:08 CET] <kierank> ah crap, didn't see that one
[03:26:17 CET] <kierank> michaelni: any idea what this 0*1 notation means? Some kind of run level thing but I don't get it
[03:26:20 CET] <kierank> https://usercontent.irccloud-cdn.com/file/6PrM23D6/
[03:38:29 CET] <kierank> durandal_1707: around?
[03:49:23 CET] <michaelni> the 0*n look like they are meant as n times a 0 value
[03:50:46 CET] <michaelni> that is a run of n zeros
[03:55:14 CET] <kierank> michaelni: ah yes that make sense, thanks
[03:55:49 CET] <kierank> fyi code i am working on is here
[03:55:49 CET] <kierank> https://github.com/kierank/ffmpeg-sstp
[03:56:05 CET] <kierank> the dc prediction stuff I think is very broke but I'd like to decode a MB cleanly first
[06:02:27 CET] <atomnuker> how to declare exposed private things, the libfftw3 way:
[06:02:34 CET] <atomnuker> enum fftw_r2r_kind_do_not_use_me {
[06:02:45 CET] <atomnuker> struct fftw_iodim_do_not_use_me {
[06:02:54 CET] <atomnuker> typedef void (*fftw_write_char_func_do_not_use_me)(char c, void *);
[07:44:32 CET] <rcombs> the correct answer being, of course, "don't"
[10:39:33 CET] <durandal_1707> atomnuker: why you use fftw3?
[10:42:06 CET] <atomnuker> I don't
[10:42:30 CET] <atomnuker> I read 2 books on ffts, wrote my own 15x2 and finally got enough knowledge to know what the current fft does
[10:43:16 CET] <atomnuker> I fixed it so it's now working correctly as a forward transform and I want to kill the bastard who didn't comment his code
[10:46:44 CET] <atomnuker> at least now I'm one of the elite few who can write a cooley-tukey fft without looking and an mdct
[10:46:57 CET] <atomnuker> (btw why is fftw3 so fast?)
[10:47:12 CET] <atomnuker> (btw WHY THE FUCK IS FFTW3 SO FUCKING FAST?)
[10:47:43 CET] <atomnuker> granted, it's a small transform which takes microseconds but still, fftw3 is 10x faster
[10:47:48 CET] <nevcairiel> because one of its Fs stands for fastest
[10:47:51 CET] <atomnuker> hell, more
[10:48:03 CET] <atomnuker> 400 000 transforms (960 len) per second
[10:48:10 CET] <atomnuker> mine can barely do 4 000
[10:48:42 CET] <nevcairiel> i've been meaning to migrate work software from kissfft to fftw since we had some performance issues on small arm devices, in the hope that it makes a real difference
[10:49:00 CET] <atomnuker> kiss_fft does 7 000
[10:49:34 CET] <atomnuker> so yeah, it'll be a drastic change, if fftw3's NEON is as good as its x86 assembly
[10:49:47 CET] <atomnuker> no, forget that, even without assembly
[10:50:19 CET] <atomnuker> how is the universe didn't explode when fftw3 become so fast is beyond me
[10:50:20 CET] <nevcairiel> fftw uses threaded parallel processing if you let it, most dont do that
[10:50:39 CET] <atomnuker> multithreading? no, it won't
[10:50:47 CET] <atomnuker> you need to compile it with openmp (ugh)
[10:51:01 CET] <nevcairiel> it claims to work with posix threads
[10:51:08 CET] <nevcairiel> but i didnt try
[10:51:27 CET] <atomnuker> well, debian's libfftw3 is compiled without threading support, the functions to init threading aren't there
[10:54:24 CET] <nevcairiel> even more fascinating then
[10:55:13 CET] <atomnuker> give me a minute and I'll send you the program with all 3 implementations so you can benchmark
[11:17:09 CET] <atomnuker> nevcairiel: https://pars.ee/temp/fft_bench.tar
[11:17:17 CET] <nevcairiel> nice, thanks
[11:17:27 CET] <atomnuker> compile with "gcc -O3 -g prog.c kiss/kiss_fft.c -lm -lrt -lfftw3f -Wall"
[11:18:08 CET] <atomnuker> adjust SSA for the size (15 * (1 << SSA)) and ITER for the number of fft->iffts to do
[11:19:25 CET] <cone-292> ffmpeg 03Bela Bodecs 07master:e7fbd7018932: avformat/hlsenc: detecting duplicated segment filenames   ffmpeg-devel
[11:20:03 CET] <atomnuker> you can just set SIZE to other numbers and benchmark powers of two, e.g., run_new will simply give an incorrect result
[16:03:09 CET] <cone-546> ffmpeg 03James Almer 07master:c3d822855cb5: avcodec/lossless_videodsp: fix output of add_hfyu_left_pred_int16_c()
[16:14:57 CET] <cone-546> ffmpeg 03Ruta Gadkari 07master:67db4ff3b66e: NVENC: Update check for Lookahead
[17:36:29 CET] <cone-546> ffmpeg 03Paul B Mahol 07master:12461636ea8c: avcodec/magicyuv: export colorspace and color_range for YUV
[18:30:49 CET] <cone-546> ffmpeg 03Bela Bodecs 07master:ce5c7260df2d: flv demuxer supports live rtmp inputs but there is no any info about it in the docs.
[18:30:50 CET] <cone-546> ffmpeg 03Michael Niedermayer 07master:89d4d7d759a5: doc/examples/http_multiclient: Fix resource leak
[20:44:28 CET] <cone-546> ffmpeg 03Paul B Mahol 07master:341d3ee44147: avcodec/ylc: do not leak memory at uninit
[20:44:29 CET] <cone-546> ffmpeg 03Paul B Mahol 07master:31bf37cba8ff: avcodec/ylc: add frame threading support
[20:44:30 CET] <cone-546> ffmpeg 03Paul B Mahol 07master:2f347c17d646: avcodec/ylc: thread safe initialization is possible with this codec
[20:45:51 CET] <cone-546> ffmpeg 03Michael Niedermayer 07master:11103a493de5: ffmpeg: Check avcodec_parameters_to_context() for failure
[00:00:00 CET] --- Tue Dec 27 2016