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

[burek]

[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