[01:38:56 CEST] <cone-656> ffmpeg 03Michael Niedermayer 07master:7ba7b96dd36b: doc/examples/http_multiclient: Fix "doc/examples/http_multiclient.c:43:9: warning: passing argument 4 of av_opt_get from incompatible pointer type" [01:41:08 CEST] <Chloe> michaelni: err, that's a massive commit message. [01:43:01 CEST] <Chloe> (I also didnt see it on the ml) [01:44:48 CEST] <jamrial_> Chloe: it's a simple fix [01:57:58 CEST] <Chloe> jamrial_: the latter comment was just an observation with no weight. And the former is just nickpicking, I guess it doesnt really matter. :/ [19:37:58 CEST] <carabia> Hey, I acknowledge it's not the completely right forum to ask this, but it's close. A question on mp3 headers. Am I guaranteed to find the first header of an mp3 file contained within the first 32 bytes of the file? [19:40:04 CEST] <carabia> well, 34 in case of the CRC? [19:56:16 CEST] <rcombs> carabia: you could easily have an ID3v2 tag larger than that [20:07:44 CEST] <Compn> carabia : to answer question, no. plenty of mp3 files without headers :D [20:08:09 CEST] <Compn> carabia : did you check our mp3 samples ? [20:08:17 CEST] <Compn> guess we dont have too many of them. [20:12:39 CEST] <carabia> Ah yes, crap. I forgot all about id3-tags. [20:13:30 CEST] <cone-646> ffmpeg 03Moritz Barsnick 07master:f71c98ee12f9: tools: fix grammar error [20:13:30 CEST] <cone-646> ffmpeg 03Moritz Barsnick 07master:3305f7102528: lavc: fix typos [20:13:31 CEST] <cone-646> ffmpeg 03Moritz Barsnick 07master:f4e4bde1f4cf: lavfi: fix typos [20:13:34 CEST] <cone-646> ffmpeg 03Moritz Barsnick 07master:468c596a31ca: lavf: fix typos [20:13:34 CEST] <cone-646> ffmpeg 03Moritz Barsnick 07master:3e5d27d7a735: cmdutils: fix typos [20:13:57 CEST] <carabia> Compn: and no i meant a frame header [20:14:21 CEST] <carabia> but yea. the id3-tags mess this one up. That needs to go first. [20:14:35 CEST] <carabia> Thanks rcombs for pointing that out, heh [21:30:19 CEST] <cone-646> ffmpeg 03Muhammad Faiz 07master:47d2be3056fa: avfilter/firequalizer: fix blackman window calculation [23:15:50 CEST] <atomnuker> michaelni: I can't replicate the segfault here [23:16:01 CEST] <atomnuker> I configure using "--cc='ccache gcc' --arch=x86_32 --target-os=linux --extra-cflags=-m32 --extra-ldflags=-m32 --enable-cross-compile --disable-devices" [23:17:56 CEST] <michaelni> atomnuker, i guess its a mater of random chance to be unaligned [23:19:19 CEST] <atomnuker> does changing every mova to movu fix the bug? [23:19:58 CEST] <atomnuker> (it should only happen in pow34 since band quantization is always done on power of two sizes) [23:24:12 CEST] <jamrial> atomnuker: assuming it's because of alignment and not overread then it should. but i think it's a better idea to align the buffers instead [23:47:34 CEST] <Gramner> atomnuker: you need to align the buffers ("float M[128], S[128];" at least, didn't check if there are others) when you use them for SIMD. it's likely that they just randomly happen to end up aligned when you're testing it so everything accidentally works [23:49:09 CEST] <Gramner> michaelni's backtrace shows that that's the reason for the crash (ecx = 0xffffc4dc is not 16-byte aligned) [00:00:00 CEST] --- Mon Oct 10 2016