[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