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

Thu Jun 8 03:05:04 EEST 2017

[00:06:19 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:eac6114e0187: avcodec/cavsdec: Fix runtime error: signed integer overflow: 59 + 2147483600 cannot be represented in type 'int'
[00:06:19 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:fc74ac463c08: avcodec/pnm: Use ff_set_dimensions()
[00:06:19 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:e3a1d133f71d: avcodec/ra144: Fixes runtime error: signed integer overflow: 7160 * 327138 cannot be represented in type 'int'
[00:06:19 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:797621afab82: avcodec/hevc_ps: Fix runtime error: signed integer overflow: 2147483628 + 256 cannot be represented in type 'int'
[00:06:19 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:706b427ff5de: avcodec/cinepak: Check input packet size before frame reallocation
[00:06:19 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:30abd8e6f982: avcodec/wavpack: Fix runtime error: signed integer overflow: 2013265955 - -134217694 cannot be represented in type 'int'
[00:06:19 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:4f02447d4568: avcodec/cfhd: Fix runtime error: signed integer overflow: 65280 * 65288 cannot be represented in type 'int'
[00:06:20 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:3dc62e679ab2: avcodec/wavpack: Fix runtime error: shift exponent 32 is too large for 32-bit type 'int'
[00:06:21 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:52a7ae844b05: avcodec/aacps: Fix runtime error: left shift of 1073741824 by 1 places cannot be represented in type 'INTFLOAT' (aka 'int')
[00:06:22 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:4e6de49a5a4a: avformat/options: log filename on open
[00:06:23 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:aae731b9d39f: avcodec/ac3dec_fixed: Fix runtime error: left shift of 419 by 23 places cannot be represented in type 'int'
[00:06:24 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:b7904b58afdd: avcodec/pafvideo: Check packet size and frame code before ff_reget_buffer()
[00:06:25 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:00312b5ea4a2: avcodec/dxv: Check remaining bytes in dxv_decompress_raw()
[00:06:26 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:0d19167a657c: avcodec/hevc_ps: Fix runtime error: index 32 out of bounds for type 'uint8_t [32]'
[00:06:27 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:cefbc513ea1c: avutil/softfloat: Fix sign error in and improve documentation of av_int2sf()
[00:06:28 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:d34d06d1e233: avcodec/qdrw: Fix null pointer dereference
[00:06:29 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:3dd1f38329e7: avformat/hls: Check local file extensions
[00:06:30 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:0fb432a23b0a: avcodec/cavs: Fix runtime error: signed integer overflow: -12648062 * 256 cannot be represented in type 'int'
[00:06:31 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:ec5e262e1d72: avcodec/tiff: Avoid loosing allocated geotag values
[00:06:32 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:34887d091d53: avcodec/mjpegdec: Check that reference frame matches the current frame
[00:06:33 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:07944df9a7d7: avcodec/takdec: Fix multiple runtime error: signed integer overflow: 637072 * 4096 cannot be represented in type 'int'
[00:06:34 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:90b6425b1285: avcodec/pafvideo: Fix assertion failure
[00:06:35 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:4c7477f132ea: avcodec/mpeg4videodec: Fix runtime error: signed integer overflow: 53098 * 40448 cannot be represented in type 'int'
[00:06:36 CEST] <cone-114> ffmpeg 03Michael Niedermayer 07release/3.3:6d7192bcb7bb: Update for 3.3.2
[00:44:09 CEST] <atomnuker> TD-Linux: what does MIPS stand for, you think?
[00:57:25 CEST] <TD-Linux> atomnuker, I can't think of any savory guesses
[00:58:59 CEST] <iive> million instructions per second?
[00:59:58 CEST] <atomnuker> TD-Linux: Much Insufficient Power Spare
[01:00:21 CEST] <TD-Linux> I like it
[04:12:05 CEST] <cone-760> ffmpeg 03Tyler Jones 07n3.3.2:HEAD: vorbisenc: Fix memory leak on errors
[06:02:41 CEST] <KGB> [13FFV1] 15dericed opened pull request #70: expanding on median predictor section (06master...06median-predictor) 02https://git.io/vHKtx
[08:21:47 CEST] <mateo`> looks like ios 11 defines a new type, named ... AVMediaType :D
[08:26:53 CEST] <kevmark> mateo`, FFmpeg baked into iOS?
[08:27:30 CEST] <mateo`> probably or apple wanting us to choose between ios and ffmpeg
[08:27:40 CEST] <mateo`> it's in the AVFoundation framework
[08:31:59 CEST] <kevmark> https://developer.apple.com/documentation/avfoundation/avmediatype
[08:32:15 CEST] <kevmark> I'm guessing it's a coincidence if only because the AV prefix is in AVFoundation
[08:35:16 CEST] <kevmark> And the AVMediaType struct from Apple is markedly different than the enum in FFmpeg 
[08:35:35 CEST] <kevmark> But maybe I'm interpreting what you're saying incorrectly
[08:39:49 CEST] <JEEB> well it's a thing that has the same name under the same namespace ;)
[08:50:49 CEST] <mateo`> kevmark: what i meant (beside the joke), is what JEEB said, it will conflict when you'll include both avformat and avfoundation in the same place
[08:51:27 CEST] <kevmark> Ahhh hah
[08:51:36 CEST] <kevmark> gg apple
[09:42:03 CEST] <rcombs> merh, their is an NSString* and ours is an enum
[09:42:50 CEST] <rcombs> that'll actually cause compile errors
[09:42:58 CEST] <ubitux> we shouldn't need AVFoundation and FFmpeg at the same time
[09:43:13 CEST] <ubitux> AVFoundation is way too high level
[09:43:26 CEST] <ubitux> ah, unless we use it as an indev hhehe
[09:44:05 CEST] <rcombs> or, wait
[09:44:16 CEST] <rcombs> ours isn't typedeffed
[09:44:34 CEST] <rcombs> so& it might just be fine
[12:21:33 CEST] <J_Darnley_irssi> Is anyone else using nasm 2.13 yet?  Do you have any problems running configure?
[12:23:07 CEST] <atomnuker> I am, haven't had any issues
[12:24:18 CEST] <RiCON> been using it since x264 required it, no problems so far
[12:24:21 CEST] <nevcairiel> i installed nasm 2.13.1, but i still have yasm installed so configure uses that
[12:24:41 CEST] <nevcairiel> 2.13.01*
[12:33:06 CEST] <cone-196> ffmpeg 03wm4 07master:66cf78e93295: lavf: consider codec framerate for framerate detection
[12:33:16 CEST] <J_Darnley_irssi> Hm...  thanks
[12:35:41 CEST] <BtbN> wm4, could that also be used for the cuvid frame doubling deinterlacing, or is that something entirely diffrent?
[12:36:08 CEST] <wm4> BtbN: what I just pushed? it only fixes framerate detection for broadcast .ts files
[12:39:22 CEST] <BtbN> hm, it only checks the probes framerate anyway
[12:41:52 CEST] <wm4> what's the problem with qsv? can't you just require that the caller sets a doubled timebase
[12:43:58 CEST] <BtbN> qsv?
[12:44:08 CEST] <BtbN> Well, in case of cuvid, you have to do exactly that.
[12:44:14 CEST] <wm4> wrong vendor... I meant cuvid
[12:44:27 CEST] <BtbN> Which is kinda annoying if you have a bunch of files with diffrent framerates and you want to deinterlace them
[12:45:07 CEST] <BtbN> I'd still like to turn the cuvid scaler/deinterlace into a filter, but I can't find any documentation on how to do that
[12:45:19 CEST] <BtbN> The API is there, but no obvious way of using it works
[12:45:22 CEST] <nevcairiel> just try all the things
[12:45:43 CEST] <BtbN> Some nvidia guy claimed it to be possible
[12:45:56 CEST] <BtbN> but never replied to me asking how
[12:46:00 CEST] <wm4> lol
[12:47:04 CEST] <BtbN> I have the generic filter done, but it just doesn't work
[12:49:35 CEST] <wm4> so almost there?
[12:51:35 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commits/nvpp
[12:51:36 CEST] <BtbN> well
[12:51:40 CEST] <BtbN> I'm out of ideas
[12:51:44 CEST] <BtbN> On how to use it
[12:51:53 CEST] <BtbN> For starters, I just wanted to make it scale
[12:52:05 CEST] <BtbN> but I have absolutely no idea how to make it process and output raw YUV
[12:54:14 CEST] <wm4> so what about it doesn't work?
[12:55:55 CEST] <BtbN> input and/or output of raw yuv
[12:56:16 CEST] <BtbN> The API is not exactly clear on how to do that, and it's not in any written documentation
[13:02:19 CEST] <wm4> aren't opaque surfaces more interesting?
[13:12:16 CEST] <BtbN> hm?
[13:12:36 CEST] <BtbN> CUDA frames are raw yuv data, so that's what needs to be processed, and it should support that, somehow
[13:16:00 CEST] <wm4> ah, I understood "raw yuv" as data in CPU memory
[13:16:21 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vHKy7
[13:16:21 CEST] <KGB> 13FFV1/06master 142113ed6 15Dave Rice: update readme to link ietf versions of ffv1...
[13:54:40 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vHKHN
[13:54:40 CEST] <KGB> 13FFV1/06master 14f566e93 15Dave Rice: equation typo...
[14:18:09 CEST] <J_Darnley_irssi> weird.  nasm is complaining that it doesn't know the -m option
[14:18:40 CEST] <J_Darnley_irssi> I wonder what patches did Arch apply to it
[14:20:06 CEST] <kierank> J_Darnley_irssi: huh
[14:20:11 CEST] <kierank> you have left the other chnanel
[14:20:57 CEST] <Gramner> there is no -m option in nasm so that's not really weird.
[14:22:19 CEST] <J_Darnley_irssi> ah
[14:22:51 CEST] <Gramner> there's also no point in using -m with yasm either. if you use the correct -f flag it will work with both
[14:23:56 CEST] <Gramner> e.g. "-f win64" instead of "-f win32 -m amd64" etc.
[14:29:38 CEST] <RiCON> J_Darnley_irssi: probably http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;hb=HEAD#l5477
[14:30:55 CEST] <RiCON> 'nasm --version' works so configure adds "-m amd64"
[14:32:42 CEST] <RiCON> libav fixed this by checking for '-v' for nasm first
[14:34:02 CEST] <nevcairiel> those fixes are scheduled for merging e ither way
[15:23:52 CEST] <J_Darnley_irssi> RiCON: oh yes
[15:35:32 CEST] <ubitux> <not supported>      cycles
[15:35:33 CEST] <ubitux> <not supported>      instructions
[15:35:35 CEST] <ubitux> fuck this shit :(
[15:36:51 CEST] <jamrial> what is that?
[15:36:52 CEST] <iive> is that some performance monitor?
[15:36:56 CEST] <DHE> it's perf
[15:36:59 CEST] <DHE> what are you running it on?
[15:37:13 CEST] <ubitux> it's perf, with a aarch64 mainline kernel on rpi3
[15:37:34 CEST] <ubitux> all the perf options seems on in the config
[15:37:58 CEST] <nevcairiel> doing that on arm was really troublesome, you should ask wbs on how to get it working
[15:37:58 CEST] <ubitux> (kernel 4.11.3)
[15:39:17 CEST] <wbs> normally perf should work out of the box, since it uses the cycle counter instruction from kernel mode (which is ok); it's if using it from userspace (like for checkasm --bench) you need to manually enable it via executing a couple instructions in kernel mode
[15:39:28 CEST] <wbs> (tl;dr can't help with that one)
[15:40:44 CEST] <ubitux> yeah, it's actually supported out of the box on the odroid
[15:41:14 CEST] <ubitux> it's just the rpi3 that's not supported
[15:41:21 CEST] <ubitux> fucking garbage
[15:41:50 CEST] <DHE> hardware, or is the kernel feature missing?
[15:42:21 CEST] <wbs> probably something along the lines of hardware/kernel combo
[15:43:26 CEST] <ubitux> yeah, so anyway, basically there is still no decent aarch64 dev board available
[15:59:21 CEST] <jamrial> what's wrong with the odroid?
[16:00:00 CEST] <wm4> bad video decoding/display drivers
[16:00:00 CEST] <mateo`> it's stuck with a 3.14 kernel
[16:46:39 CEST] <ubitux> jamrial: i updated my aacpsdsp branch to actually test the results from the functions in checkasm
[16:46:51 CEST] <ubitux> and it appears to fail on x86 (but not aarch64)
[16:47:04 CEST] <ubitux> but maybe i'm doing sth wrong
[16:47:18 CEST] <ubitux> stereo_interpolate_ipdopd_sse3 is failing
[16:47:36 CEST] <ubitux> like, it looks like the first entry is wrong (but not the others)
[16:48:22 CEST] <ubitux> also, the test don't seem to like with a stride of 1 but i may have broken something
[17:40:09 CEST] <jamrial> ubitux: huh, weird seeing that the standard fate test for ipdopd passes
[17:48:57 CEST] <jamrial> also, remove all that INTFLOAT stuff, it's not needed here
[18:18:46 CEST] <Compn> michaelni : i'm going to be away for a week. june 8-15. just fyi about mailing list moderations
[18:29:12 CEST] <durandal_1707> Compn: give your admin flag to me
[18:30:38 CEST] <jamrial> man, fuck you fate-aac-al_sbr_ps_04_ur
[18:31:19 CEST] <jamrial> ubitux: found what was wrong. i'm surprised the above test didn't complain about it
[18:54:49 CEST] <cone-148> ffmpeg 03James Almer 07master:497a4b554c8d: x86/aacpsdsp: fix output of ff_ps_stereo_interpolate_ipdopd_sse3
[18:55:21 CEST] <jamrial> ubitux: ^ thanks for pointing it out
[19:25:09 CEST] <J_Darnley> I'll probably send an email on this topic too...
[19:25:55 CEST] <J_Darnley> To support nasm 2.13 I wonder whether I should steal Libav's configure code for probing,
[19:25:58 CEST] <J_Darnley> merge it,
[19:26:30 CEST] <J_Darnley> put a band-aid on ours by swapping the checks.
[19:26:58 CEST] <atomnuker> can't we just pick nasm by default
[19:27:46 CEST] <J_Darnley> Sure.  I would be willing to follow x264's lead and require 2.13 but I bet other are not.
[19:29:23 CEST] <iive> my distro hasn't shipped 2.13 yet.
[19:29:50 CEST] <J_Darnley> Get with the times!  It is $CURRENT_DAY  :)
[19:29:52 CEST] <JEEB> debian put it into experimental so I could build packages :3
[19:30:18 CEST] <Gramner> debian stable might support 2.13 in 3 years or so
[19:30:47 CEST] <J_Darnley> Perhaps a compromise of the "new" development of nasm would be acceptable.
[19:30:55 CEST] <J_Darnley> 2.10-something I think
[19:32:13 CEST] <iive> btw, does configure have an option that would make it pick nasm over yasm (or vice versa) if both are installed?
[19:32:47 CEST] <J_Darnley> Yes: --yasmexe=anything_other_than_yasm
[19:33:09 CEST] <iive> that's somehow hackish
[19:33:17 CEST] <Gramner> 2.13 is required for avx-512 (because 2.12 was a minefield of evex bugs until I stumbled across them and fixed them myself or made someone else fix them) and self-relative addressing. ffmpeg uses neither at the moment so there's not really much point in requiring 2.13
[19:33:23 CEST] <J_Darnley> if the check for $yasmexe --version fails it will force yasmexe=nasm
[19:34:31 CEST] <iive> Gramner: i guess yasm doesn't support avx-512 at all?
[19:34:47 CEST] <Gramner> i should probably port the x86inc avx-512 changes to ffmpeg though if someone else wants to start cracking away on it
[19:34:51 CEST] <J_Darnley> I think it doesn't even support all of AVX2
[19:34:53 CEST] <Gramner> correct. no avx-512 in yasm
[19:35:25 CEST] <Gramner> avx2 is fully supported in yasm, at least I haven't noticed anything that isn't
[19:35:31 CEST] <J_Darnley> I think there was some fused multiply-add or XOP instruction I wanted to use in flac but the assembler didn't recognise it.
[19:35:45 CEST] <J_Darnley> (I guess XOP isn't AVX2)
[19:35:55 CEST] <Gramner> xop is dead though, I wouldn't spend any time on writing such code
[19:36:09 CEST] <J_Darnley> That was 2+ years ago.
[19:36:10 CEST] <iive> is it fma3/4 like ?
[19:36:19 CEST] <J_Darnley> Yes, but for integers
[19:36:20 CEST] <ubitux> jamrial: nice! :)
[19:36:39 CEST] <J_Darnley> Gramner: I will tackle importing the x264asm changes.
[19:36:40 CEST] <ubitux> jamrial: about INTFLOAT, it makes supporting fixed later simpler
[19:36:42 CEST] <Gramner> xop was nice for horizontal stuff. a shame intel doesn't seem to care about that
[19:36:56 CEST] <Gramner> and that onle gets worse as vector widths increases
[19:37:12 CEST] <Gramner> many use cases require summing all values in a register
[19:37:50 CEST] <iive> and accessing higher parts of registers is uglier and uglier
[19:37:57 CEST] <Gramner> which currently results in a ton of shuffle -> add -> shuffle -> add -> repeat
[19:38:11 CEST] <Gramner> and two of those are cross-lane shuiffles when summing a zmm reg
[19:38:23 CEST] <Gramner> so it takes forever
[19:39:09 CEST] <iive> imho, they should have made the avx1/2 use joined registers
[19:39:43 CEST] <Gramner> no, the lane stuff makes a lot of sense to be honest. I hated it at first but I've gotten used to it
[19:39:50 CEST] <iive> aka, make xmm32-63 and let the new operations use the pair xmm0/xmm32
[19:39:54 CEST] <Gramner> and avx-512 helps a lot with the new shuffles
[19:40:26 CEST] <iive> i'd love line stuff..
[19:41:39 CEST] <iive> my point is ... the new ymm operations does act like they are 2 joined xmm operations, the high and low halves of registers are separate.
[19:43:28 CEST] <iive> and the extension to this idea is to have not just 2 but n-th joined registers, where n is written in the instruction prefix.
[19:46:29 CEST] <Gramner> not sure if that'd be very useful compared to the significant complexity increase
[19:46:48 CEST] <iive> there is no really a complexit increase
[19:46:53 CEST] <iive> quite the contrary
[19:47:34 CEST] <iive> e.g. with register size of 512, you do 4x128 operations. if you have 4 op units
[19:48:05 CEST] <iive> you can pick if you want to do 4 different ops on 4 different xmm registers or 1x512
[19:49:37 CEST] <Gramner> that's basically how many cpus work internally already. amd does avx2 like that one every cpu, but's it's an implementation detail and you don't want to expose every implementation detail or you'll be forced to support that specific way of doing things forever
[19:49:54 CEST] <iive> instead, we have a power-save feature that turns off the high register part if it is not used, and it takes 60000 clocks to power it up at first use.
[19:50:49 CEST] <iive> Gramner: that's the whole point. that's how cpu work already. it doesn't need anything new or complicated
[19:50:53 CEST] <Gramner> the power gating and thermal throttling of SIMD registers sucks balls, but that feels more like a poor architectural design than and instruction set issue
[19:51:34 CEST] <iive> Gramner: it just means that the high part is not used at all. just wasted die.
[19:51:49 CEST] <iive> also, who would not like 4 or 8 time more registers?
[19:52:53 CEST] <J_Darnley> Reminds me of my old Athlon64.  I'm not sure I ever ran 64-bit code on it.
[19:54:35 CEST] <Gramner> I don't really see the need for going from 32 simd registers to 128 though. not sure what the use case for that is
[19:55:51 CEST] <jamrial> 64 regs would be ideal for avx512, as BBB once mentioned. just like avx2 should have bumped it to 32
[19:56:03 CEST] <jamrial> perfect for transpose
[19:56:43 CEST] <Gramner> also twice as much stuff to backup and restore on context switches
[19:57:06 CEST] <iive> but you see, that the whole point
[19:57:16 CEST] <iive> it is the same number of bits
[19:57:25 CEST] <iive> aka 4 xmm regs or 1 ymm
[19:57:44 CEST] <iive> you just break 1ymm on 4 addressable xmm registers
[19:58:00 CEST] <iive> you can do permutations on them with mov.
[19:58:23 CEST] <iive> instead of extracts that take 5 cycles each
[19:58:59 CEST] <jamrial> iive: ymm is twice the size of xmm. you're thinking zmm
[19:59:07 CEST] <iive> yep, sorry
[20:00:53 CEST] <Gramner> why even have wider registers then? if you want 256-bit ops to run at half the speed of 128-bit (and 512-bit at 1/4 the speed) just stick with a 128-bit instruction set and skip the complexity
[20:01:17 CEST] <iive> to have shorter opcodes
[20:01:27 CEST] <iive> the same reason we have zmm ops now.
[20:01:42 CEST] <J_Darnley> Bye again
[20:01:45 CEST] <iive> actually i just had the idea, how about using the existing prefix "rep"
[20:09:45 CEST] <iive> Gramner: 512bit ops does 4 x128 in parallel. they do it now, the 128 parts are separate.
[20:10:05 CEST] <iive> So I do not see it as 512 been slower, but as 128 been 4 times faster.
[21:40:51 CEST] <blue_misfit> hey guys! Should ffmpeg libraries theoretically support QuickTime MOV files with mixed types of video in a given track? e.g. prores + dnxhd
[21:41:04 CEST] <blue_misfit> apparently this is possible to make in Avid, and native QuickTime apps like Premiere handle it just fine, crazily enough
[21:46:15 CEST] <jamrial_> ubitux: https://github.com/jamrial/FFmpeg/commits/aarch64-aac couple changes you can squash
[21:53:12 CEST] <durandal_170> blue_misfit: i doubt, why not try anyway, have a sample?
[21:54:32 CEST] <blue_misfit> I do have a sample but I can't share (high security) but I'll try to make one that's low security. The file I looked at started with dnxhd which transcoded fine but when it switches to prores the output has black frames. When it switches back to dnxhd it recovers :)
[22:58:34 CEST] <rcombs> blue_misfit: 0.o who does this
[22:58:56 CEST] <rcombs> though actually, I need this for MPEGTS (broadcast TV)
[22:59:13 CEST] <nevcairiel> in general we dont support this, no.
[23:00:10 CEST] <nevcairiel> and it would probably be hard to do that as well, since there are many structures that depend on the codec and driving a re-init through everything would be rather complex
[23:06:30 CEST] <wm4> obviously this should happen on a higher level
[23:06:36 CEST] <wm4> mpv supports it
[23:06:54 CEST] <wm4> and *shock* that didn't need lavc API changes
[23:08:21 CEST] <rcombs> yeah, I'd imagine it'd be in the API consumer, perhaps with some assistance from lavf
[23:42:47 CEST] <fiberbaby> https://www.ssllabs.com/ssltest/analyze.html?d=ffmpeg.org
[23:42:54 CEST] <fiberbaby> https://blog.qualys.com/ssllabs/2017/04/05/ssl-labs-distrusts-wosign-and-startcom-certificates
[23:43:04 CEST] <fiberbaby> how about using Let's Encrypt
[00:00:00 CEST] --- Thu Jun  8 2017