[01:04:54 CET] <kierank> atomnuker: seen that http://src.infinitewave.ca/ [01:05:16 CET] <cone-541> ffmpeg 03Michael Niedermayer 07master:45198477de19: avcodec/simple_idct_template: Fix several integer overflows [01:05:17 CET] <cone-541> ffmpeg 03Michael Niedermayer 07master:58e9c7f4a2fd: avcodec/wavpack: Fix multiple integer overflows [01:05:18 CET] <cone-541> ffmpeg 03Michael Niedermayer 07master:cfa10e11be4c: avcodec/tiff: Check palette shift [01:20:11 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:25bacd0a0c32: Don't use expressions with side effects in macro parameters [01:20:12 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:014773b66bdf: libavutil: Use an intermediate variable in AV_COPY*U [01:20:13 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:230b1c070baa: intreadwrite: Add intermediate variables in the byteswise AV_W*() macros [01:20:14 CET] <cone-541> ffmpeg 03James Almer 07master:eedb44a605ce: Merge commit '25bacd0a0c32ae682e6f411b1ac9020aeaabca72' [01:20:15 CET] <cone-541> ffmpeg 03James Almer 07master:4708f978902b: Merge commit '014773b66bdff4de24f384066d1a85d2a5bb6774' [01:20:16 CET] <cone-541> ffmpeg 03James Almer 07master:916dff9cb102: Merge commit '230b1c070baa3b6d4bd590426a365b843d60ff50' [01:32:27 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:f79d847400d2: intreadwrite: Use the __unaligned keyword on MSVC for ARM and x86_64 [01:32:28 CET] <cone-541> ffmpeg 03James Almer 07master:30fe4b8d4ce2: Merge commit 'f79d847400d218cfd0b95f10358fe6e65ec3c9c4' [01:34:50 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:9806b9ab5c7f: Revert "Don't use expressions with side effects in macro parameters" [01:34:51 CET] <cone-541> ffmpeg 03Martin Storsjö 07master:fc94a1acc27a: Revert "libavutil: Use an intermediate variable in AV_COPY*U" [01:34:52 CET] <cone-541> ffmpeg 03James Almer 07master:86fb169df589: Merge commit '9806b9ab5c7fb2ac5efd8ffa8713fea0c5fd218d' [01:34:53 CET] <cone-541> ffmpeg 03James Almer 07master:8c0aacf0ec77: Merge commit 'fc94a1acc27ab7296edce3fa81ef36691af5c134' [01:37:12 CET] <cone-541> ffmpeg 03Diego Biurrun 07master:e723dce6f8ba: dvbsubdec: Use NULL instead of 0 as pointer value [01:37:13 CET] <cone-541> ffmpeg 03James Almer 07master:f073b2da8410: Merge commit 'e723dce6f8ba1e8260433b6ecfe5a3262f4c7a99' [01:39:19 CET] <cone-541> ffmpeg 03Diego Biurrun 07master:3ccec334b850: sbrdsp: Move a misplaced #endif directive to the right spot [01:39:20 CET] <cone-541> ffmpeg 03James Almer 07master:e298497f0c6e: Merge commit '3ccec334b8502701e72ef13bed25913c3578022e' [01:41:36 CET] <uau> jamrial: any reason to make separate merge commits for all those? even the consecutive merges that didn't change the tree? [01:42:29 CET] <wm4> maybe it's easier [01:42:32 CET] <jamrial> uau: never did single merge for several commits, so not sure how [01:42:48 CET] <jamrial> wm4: well, less prone to failure at least [01:42:50 CET] <uau> it's not any different? [01:43:03 CET] <nevcairiel> easier to keep track of things, and special casing a few special cases seems like extra effort not really worth it [01:43:04 CET] <uau> i mean you generally merge an arbitrary other tree [01:43:23 CET] <uau> whether it has one or more commits that do not exist in your current tree doesn't really make it any different [01:43:35 CET] <jamrial> also, i can reference the commit in our tree that already changed the code the merge would otherwise affect [01:44:05 CET] <nevcairiel> its usually a good idea to write down why a commit was skipped, indeed [01:45:10 CET] <uau> nevcairiel: in this case "merge -s ours COMMIT" with a message containing "skip, these were reverted in libav" should communicate everything relevant though [01:45:44 CET] <nevcairiel> perhaps, but its safer to just stick to the same pattern for all of them, i guess [01:45:45 CET] <cone-541> ffmpeg 03Michael Niedermayer 07master:e5b019725f53: m4vdec: Check for non-startcode 00 00 00 sequences in probe [01:45:46 CET] <cone-541> ffmpeg 03Anton Khirnov 07master:d3e4d406b020: h264dec: reset nb_slice_ctx_queued for hwaccel decoding [01:45:47 CET] <cone-541> ffmpeg 03James Almer 07master:67817468d3fd: Merge commit 'e5b019725f53b79159931d3a7317107cbbfd0860' [01:45:48 CET] <cone-541> ffmpeg 03James Almer 07master:65ff562c3b30: Merge commit 'd3e4d406b020b0464486318aceda08bd8f69ca41' [01:45:52 CET] <nevcairiel> such cases are extremely rare either way [01:46:27 CET] <wm4> did anyone look at the frame thread atomics changes yet? and the hwaccel threading patches? [01:49:46 CET] <jamrial> uau: so basically, git merge -s ours --no-commit HASH1 && git merge -s ours --no-commit HASH2 && git commit? [01:50:07 CET] <nevcairiel> nah, just use the hash of the last hash in the series [01:50:07 CET] <uau> jamrial: no, just the second [01:50:23 CET] <jamrial> ok, will keep that in mind [01:50:25 CET] <uau> you merge all changes in the given tree which don't already exist in your current one [01:50:34 CET] <uau> not individual commits [02:09:22 CET] <cone-541> ffmpeg 03Christophe Gisquet 07master:3c504bc3599f: x86: deduplicate some constants [02:09:23 CET] <cone-541> ffmpeg 03James Almer 07master:e632fe9babe9: Merge commit '3c504bc3599f00bfc5923adc114beef34bce11d0' [02:18:34 CET] <cone-541> ffmpeg 03James Almer 07master:63ac8e2d9308: lavu: add LOCAL_ALIGNED_32 [02:18:35 CET] <cone-541> ffmpeg 03Anton Khirnov 07master:89aebc5bcc6e: lavc: align the linesize to 32 when AVX is enabled [02:18:36 CET] <cone-541> ffmpeg 03James Almer 07master:b5122b040fe9: Merge commit '63ac8e2d93080b74f6be32c7c3c1a1e44aacf34e' [02:18:37 CET] <cone-541> ffmpeg 03James Almer 07master:6c4665deb4d2: Merge commit '89aebc5bcc6e23a0a79c3f51c3a55c3571692ba0' [02:23:20 CET] <jamrial> ubitux: there, cleared some of the backlog [02:23:39 CET] <jamrial> a lot of vp9 commits cherry picked from our tree circa 2013 come next [02:24:29 CET] <jamrial> imo, just noop them all and don't even bother checking if they made cosmetic changes [03:05:29 CET] <wm4> jamrial: definitely, BBB maintains his vp9 decoder well [03:05:34 CET] <wm4> you'd probably just add bugs [03:06:05 CET] <jamrial> that, plus these are four years old commits, so even cosmetic differences would probably not even apply [06:11:35 CET] <wm4> wasn't there something about sox being faster than swr? [06:11:53 CET] <wm4> because someone just posted some more swr optimizations [08:00:29 CET] <cone-551> ffmpeg 03Rostislav Pehlivanov 07master:911417f0b34e: ffmpeg: don't use resample_lavr_opts [08:17:57 CET] <TD-Linux> wm4, no there was this https://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/207981.html [08:18:41 CET] <TD-Linux> that looks like aliasing at like -75db, if that can be repeated that's pretty bad quality from swr [08:19:15 CET] <wm4> oh [08:22:15 CET] <TD-Linux> I would really expect the default to be closer to the noise floor of 16 bit audio (-96db) [08:29:38 CET] <wm4> why is -96db the noise floor of 16 bit audio? [09:23:13 CET] <memeka> hi; i have been playing around with some patches that add v4l2 encoder/decoder support to ffmpeg and i have some issues with encoding: while in 3.0.2 it works well, in 3.2.4 I lose the fps information from output file, I get like all frames in the clip in 1 second kind of, e.g. ffmpeg -i encoded.mp4 looks like: Stream #0:0(und): Video: h264 (Main) (avc1 / [09:23:13 CET] <memeka> 0x31637661), yuv420p, 1280x720, 868799 kb/s, 12800 fps, 12800 tbr, 12800 tbn, 25600 tbc (default) ----- 12800fps! (input was 25fps) .... [09:23:43 CET] <memeka> was there anything changed regarding encoding fps between 3.0 and 3.2 ?? [09:23:53 CET] <memeka> that could affect this? [09:25:43 CET] <memeka> i also get: "[mp4 @ 0x7f69b960] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly" and "[mp4 @ 0x7f69b960] Encoder did not produce proper pts, making some up." -- but i was getting this in 3.0.2 as well and the result was ok [09:54:29 CET] <durandal_170> why s32 is not asm optimized in libswr? [10:10:45 CET] <durandal_170> wm4: 96db is min that can be represented by 16 bit [10:12:39 CET] <nevcairiel> there is a formula for that .. 20 * log10(2^bits) [10:16:10 CET] <nevcairiel> or around 6 dB per bit [10:23:38 CET] <nevcairiel> heh even AMDs quad cores will use 2 CCX for a 2+2 combination, guess recycling is the way to go. If some of the performance troubles really come from the slow link between the two core complexes, thats a bit of a shame [10:52:25 CET] <mateo`> I'll push the aarch64 simpleneon idct patchset in a few minutes [11:03:36 CET] <cone-551> ffmpeg 03Matthieu Bouron 07master:4c8e528d19a3: lavc/aarch64: add ff_simple_idct{,_add,_put}_neon functions [11:03:37 CET] <cone-551> ffmpeg 03Matthieu Bouron 07master:0c6105dde0c4: lavc/tests/dct/aarch64: add ff_simple_idct_neon test [11:04:41 CET] <BtbN> nevcairiel, yeah, I'd guess at least the R5 and R7 are all made from the same die [11:04:51 CET] <BtbN> The R3 probably as well [11:10:13 CET] <BtbN> So there is no point in getting any of the smaller models, except for budget [11:10:20 CET] <BtbN> They don't even clock higher [12:56:28 CET] <memeka> when transcoding a file, the result has wrong fps (like 12000 fps) ... i tried using -r parameter but it's ignored .... any help? [13:48:37 CET] <aballier> michaelni: ping; did you notice i sent a followup to the vf_framerate patch ? (but failed to set v2 in subject or email headers...) [14:55:11 CET] <matkatmusic> are there any guidelines or steps for using the API to write to specific frame numbers? [15:05:08 CET] <durandal_1707> matkatmusic: no [15:24:44 CET] <matkatmusic> what about a guide that explains the design concept for creating video files with ffmpeg? [15:24:54 CET] <matkatmusic> from a programmers' point of view [15:50:06 CET] <endle> Excuse me, how can I disable "-Wdeprecated-declarations" warnings while compiling ffmpeg? [15:55:38 CET] <flux> arrange -Wno-deprecated-declarations to be used as a compiler flag? [16:01:01 CET] <J_Darnley> what ^ said: --extra-cflags [16:07:00 CET] <J_Darnley> Does moving (with mov) a byte/word/dword into the low byte/word/dword of a general purpose resiter change the contents of the high part? [16:08:14 CET] <endle> Thanks, it works [16:08:33 CET] <endle> Is ffmpeg accepting tiny patches only fixing a compile warning? [16:08:58 CET] <J_Darnley> Usually that depends on the warning [16:09:46 CET] <J_Darnley> Some compilers are overzealous with their warnings. [16:10:19 CET] <J_Darnley> If it is in a header which prodces many warnings in many C files then that is more likely. [16:10:36 CET] <J_Darnley> Why not say what warning? Or just submit anyway? [16:12:33 CET] <endle> Well, I want to submit some small patches to get familiar with ffmpeg's workflow [16:13:03 CET] <endle> By the way, why "http://coverage.ffmpeg.org/" is on 404 error? Temporary down? [16:13:15 CET] <J_Darnley> I don't know [16:16:30 CET] <J_Darnley> OMFG! The tiniest little typo! I curse this choice of variable name: dst and dst2 [16:17:10 CET] <cone-551> ffmpeg 03Alexis Ballier 07master:bbc8f3d20e09: lavf/vf_framerate: Fix frame leak when increasing framerate. [16:17:11 CET] <cone-551> ffmpeg 03Alexis Ballier 07master:21bed3c981d1: fate: Add vf_framerate test. [16:17:12 CET] <cone-551> ffmpeg 03Michael Niedermayer 07master:2898bc522da6: avcodec/h264idct_template: fix multiple runtime error: signed integer overflow [16:17:13 CET] <cone-551> ffmpeg 03Michael Niedermayer 07master:a3a408259912: avcodec/h264_cabac: Fix runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself [16:26:59 CET] <jamrial> J_Darnley: i think the lower 32 bits are not affected. only the high 32 bits on x86_64 gprs are cleared if you use dword or less [16:44:57 CET] <ubitux> jamrial: thx for yesterday; i'll work on the merge later today [16:45:05 CET] <jamrial> no prob [16:45:12 CET] <ubitux> endle: yes it's down for now, i need time to fix this, sorry about that [16:50:54 CET] <endle> ubitux, good luck:) [17:00:17 CET] <J_Darnley> endle: I forgot to ask. Does your change fix the warning or just hide it? (like with a cast) [17:00:50 CET] <endle> J_Darnley, for example, const int *p=(int*)s; [17:01:18 CET] <J_Darnley> Yeah. We are not a C++ project [17:01:25 CET] <endle> this caused a warning, and change (int*) to (const int *) is the fix, right? [17:01:56 CET] <endle> If I can guarantee that s is int* or const int* [17:58:21 CET] <wm4> does anyone have contact with Sascha Sommer? since he was a ffmpeg contributor too [18:06:25 CET] <J_Darnley> lolwut? yasm doesn't have %unmaco [18:30:45 CET] <cone-551> ffmpeg 03Muhammad Faiz 07master:1f7eb216b085: swresample/options: enable linear_interp and exact_rational by default [18:36:19 CET] <J_Darnley> WTF yasm! What is wrong with "movsx rNq, dword [...]"? [18:36:38 CET] <jamrial> use movsxd [18:37:59 CET] <jamrial> for a dword source (mem or reg) it's movsxd. movsx is for any other source [18:38:24 CET] <J_Darnley> Ah. Now I see nasm does that for me. [18:38:52 CET] <J_Darnley> Sneaky bastard [18:54:40 CET] <JEEB> always fun when things do automagic for you [19:16:17 CET] <wm4> michaelni: can you approve/disapprove the side data merging deprecation patch, so I can push it? [19:25:04 CET] <iive> LOL [19:30:28 CET] <wm4> iive: yes? [19:31:22 CET] <iive> your wording implies that you are going to push it, even if michael disapproves ;) [19:32:02 CET] <wm4> no, disapproval would mean there are some change requests, which I would do, and then would push (after approval) [19:32:30 CET] <wm4> what I don't want is that the patch has to bitrot for a week or so until maintainer timeout hits [19:33:36 CET] <iive> sure, but the wording was still funny. [19:42:39 CET] <ubitux> michaelni: coverage is back for now, not sure for how long [19:43:33 CET] <BtbN> it was gone? [19:44:48 CET] <ubitux> yeah this machine shits on itself on a regular basis [19:44:55 CET] <ubitux> i'm working on it [19:45:37 CET] <BtbN> The travis machine? [19:45:51 CET] <BtbN> I'm getting E-Mails from it constantly, seems to be running fine [19:46:26 CET] <BtbN> Ot id coverage something else than coverity? [19:46:32 CET] <BtbN> *Or is [19:47:17 CET] <atomnuker> could someone look at my lavr_sws deprecation patch to see if there's something wrong with it? [19:52:28 CET] <wm4> atomnuker: done [19:58:49 CET] <ubitux> BtbN: no it's running on my machine [19:59:17 CET] <BtbN> But we migrated it to run on TravisCi a while ago [19:59:29 CET] <BtbN> https://github.com/FFmpeg/FFmpeg-Coverity [19:59:46 CET] <BtbN> https://travis-ci.org/FFmpeg/FFmpeg-Coverity [20:00:21 CET] <ubitux> coverage ` coverity [20:00:24 CET] <ubitux> http://coverage.ffmpeg.org/ [20:00:45 CET] <BtbN> So it is something else, ok [20:01:10 CET] <BtbN> I guess that could also be done on a travis machine? [20:03:22 CET] <ubitux> http://lucy.pkh.me/ffmpeg-coverage-snapshots/ [20:03:25 CET] <ubitux> there is also this [20:03:34 CET] <ubitux> supposed to allow you to compare between runs [20:03:43 CET] <ubitux> but i guess no one uses it [20:13:54 CET] <cone-551> ffmpeg 03Anton Khirnov 07master:89466de4aeaf: vp9/x86: rename vp9dsp to vp9mc [20:13:55 CET] <cone-551> ffmpeg 03Clément BSsch 07master:a4f5e79f7cef: Merge commit '89466de4aeaf5e359489b81b8a9920a2bc7936d6' [20:27:42 CET] <cone-551> ffmpeg 03Ronald S. Bultje 07master:3a09494939dd: vp9mc/x86: add 16px functions (64bit only). [20:27:43 CET] <cone-551> ffmpeg 03Clément BSsch 07master:6ab642d69d18: vp9mc/x86: simplify a few inits. [20:27:44 CET] <cone-551> ffmpeg 03James Almer 07master:8be8444d01d8: vp9mc/x86: rename ff_avg[48]_sse to ff_avg[48]_mmxext [20:27:45 CET] <cone-551> ffmpeg 03Clément BSsch 07master:3cda179f180e: vp9mc/x86: rename ff_* to ff_vp9_* [20:27:46 CET] <cone-551> ffmpeg 03James Almer 07master:67922b4ee48b: vp9mc/x86: add AVX and AVX2 MC [20:27:47 CET] <cone-551> ffmpeg 03Ronald S. Bultje 07master:9790b44a89d1: vp9mc/x86: sse2 MC assembly. [20:27:48 CET] <cone-551> ffmpeg 03Ronald S. Bultje 07master:e99ecda55082: checkasm: add vp9 MC tests. [20:27:49 CET] <cone-551> ffmpeg 03Clément BSsch 07master:8286c359ad45: Merge commit 'e99ecda55082cb9dde8fd349361e169dc383943a' [20:28:13 CET] <jamrial> what i don't like of coverage is how all the fail code paths we have contribute to the awful coverage percentages [20:29:13 CET] <jamrial> like, some demuxers have complete coverage of actual code, but all the fail paths make it report like it's 80% or even less [20:29:32 CET] <ubitux> in a sense, that's actually a good thing to point out [20:29:41 CET] <ubitux> because failing code is almost never tested [20:29:58 CET] <ubitux> and could reveal memleaks or crashes in the error unstacking [20:30:10 CET] <ubitux> ideally, we should test failing code paths [20:30:54 CET] <ubitux> OTOH, testing every code allocation within a fate coverage is a bit non sense [20:31:19 CET] <jamrial> failing code paths are mostly tested with fuzzing [20:31:36 CET] <ubitux> wm4: does 24a362569bff1d4161742fffaca80a4a4428be8a affect ffmpeg? [20:31:39 CET] <BtbN> unless for random OOMs [20:31:56 CET] <ubitux> wm4: i suppose so, but just checking before merging [20:32:11 CET] <BtbN> Is there like a fuzz-allocator, that randomly fails like 1% of mallocs? [20:34:07 CET] <ubitux> i think derek wrote something like that some day [20:37:02 CET] <cone-551> ffmpeg 03Lou Logan 07master:e7282674a505: lavf/mpegtsenc: clarify pcr_period unit of measurement [20:59:04 CET] <cone-551> ffmpeg 03wang-bin 07master:b573e3f4845b: configure: clang -Oz for small size build to reduce size further [21:02:54 CET] <cone-551> ffmpeg 03Lou Logan 07master:396be0da59fa: doc/muxers: cleanup mpegts section [21:06:04 CET] <wm4> ubitux: not sure, but it looks like the ffmpeg code has the same problem [21:09:49 CET] <cone-551> ffmpeg 03Carl Eugen Hoyos 07master:0d34dbc27277: lavc/avpacket: Make pkt parameter of av_packet_get_side_data() const. [21:10:59 CET] <J_Darnley> Why has linking on Windows/Cygwin become so slow? I swear it gets worse every time gcc gets updated. [21:12:26 CET] <BtbN> doesn't seem overly slow to me [21:15:43 CET] <J_Darnley> Perhaps I've been using Linux too much so Windows' speed penalty just seems too much now. [21:16:05 CET] <cone-551> ffmpeg 03Carl Eugen Hoyos 07master:5dd7ea9f569b: lavc/internal: Constify AVPacket* in AVCodecInternal. [21:16:17 CET] <BtbN> it's just cygwin fork emu that's a bit slow [21:16:21 CET] <BtbN> but it's not too horrible [21:16:24 CET] <J_Darnley> I stillt hink 46 seconds to link ffmpeg is a long time [21:16:29 CET] <J_Darnley> *still think [21:16:41 CET] <RiCON> that's about right for windows [21:17:32 CET] <durandal_1707> wtf, now we are adding overflow messages all over the code? [21:20:08 CET] <durandal_1707> av_request_sample(avctx, "i just made a po\n"); [21:22:28 CET] <BtbN> make -j16 976,53s user 205,51s system 1032% cpu 1:54,50 total [21:22:44 CET] <BtbN> That's on Cygwin 64bit, a full make [21:24:08 CET] <J_Darnley> Mmm 16 threads, I'm jealous. [21:24:14 CET] <BtbN> make -j16 19,44s user 1,65s system 98% cpu 21,506 total [21:24:18 CET] <BtbN> if I rm ffmpeg_g.exe [21:24:56 CET] <BtbN> So it does spend a substantial amount of time on linking [21:25:15 CET] <BtbN> But this is also on a 3GB/s NVMe drive [21:25:28 CET] <BtbN> Can easily see it being super slow on a spinning disk [21:27:57 CET] <jamrial> yes, linking on mingw/msys2 trashes my hdd like mad [21:29:34 CET] <BtbN> I'd guess it's primarily slow on win32 because of NTFS not being exactly an amazing FS [21:30:12 CET] <J_Darnley> I remember the hype 10+ years ago. [21:30:26 CET] <J_Darnley> "NTFS will not need defragging" [21:30:47 CET] <JEEB> that was probably closer to 20 years ago [21:30:58 CET] <JEEB> since NTFS was already in use in win2000 and probably in NT4 [21:31:13 CET] <J_Darnley> Meh, when home users were moving to 2000/XP [21:31:19 CET] <BtbN> Todays NTFS is like ext4 compared to ext2 for it though [21:41:36 CET] <ubitux> wm4: ok [21:47:30 CET] <cone-551> ffmpeg 03Anton Khirnov 07master:24a362569bff: buffer: fix av_buffer_realloc() when the data is offset wrt buffer start [21:47:32 CET] <cone-551> ffmpeg 03Ronald S. Bultje 07master:0df4801105d8: vp9: make mv bounds 32bit. [21:47:33 CET] <cone-551> ffmpeg 03Clément BSsch 07master:5e4a5726995c: Merge commit '24a362569bff1d4161742fffaca80a4a4428be8a' [21:47:34 CET] <cone-551> ffmpeg 03Clément BSsch 07master:d006a075b89c: Merge commit '0df4801105d84883071b0978cb3afc7cd5184ce8' [21:48:02 CET] <ubitux> i'll stop the merge for today; i think mateo` will have a look to merging the next commit (aiff) [21:48:07 CET] <ubitux> i'll go back to the merges after that [21:48:38 CET] <durandal_1707> aiff what? [21:48:53 CET] <ubitux> a dubious fix, 0638b99cdb [21:49:18 CET] <ubitux> mateo` worked on this so i'm leaving it to him [22:18:35 CET] <cone-551> ffmpeg 03Carl Eugen Hoyos 07master:1cd58e915436: lavu/spherical: Make AVSphericalMapping pointer parameter const. [22:58:58 CET] <Compn> anyone know how to contact sascha sommer ? [22:59:09 CET] <Compn> he was listed in ffmpeg gsoc 2016 as a mentor [22:59:13 CET] <Compn> his emails are bouncing now [22:59:34 CET] <wm4> well his main email is not bouncing, just /dev/nulling [00:00:00 CET] --- Fri Mar 17 2017