On 23.04.2018 21:33, Rostislav Pehlivanov wrote: > On 23 April 2018 at 20:16, Thomas Volkert <si...@gmx.net> wrote: > >> On 23.04.2018 11:27, Thomas Volkert wrote: >>> On 22.04.2018 20:03, Carl Eugen Hoyos wrote: >>>> 2018-04-22 20:00 GMT+02:00, Nicolas George <geo...@nsup.org>: >>>>> Carl Eugen Hoyos (2018-04-22): >>>>>> How do you detect that this is not the "current version" of mbed? >>>>> Is it really our responsibility? >>>> We try to always do it and I believe that allowing LGPL makes >>>> more sense and less headache: Since we do the checks so >>>> rigorously it makes sense to assume we did it as correctly >>>> for this case. >>>> >>>> I don't understand why we don't go the easy way that clearly >>>> has advantages instead for the complicated way (with at >>>> least some disadvantages). >>> Okay. I looked over their web page and the Debian packages again. >>> The web page of mbedTLS declares Apache license as the "primary open >>> source license". >>> >>> I will add it to EXTERNAL_LIBRARY_VERSION3_LIST and push it today, if >>> their are no further objections. >> pushed >> >> >> Sorry, had to revert, I'd still like to know what gains (disk space, >> performance, maybe security-wise too if possible), this would have over >> existing TLS libraries. Code-wise it looked fine. >> Okay.
Is the idea to have a detailed comparison (measurement values, feature comparison) between the TLS implementations and then decide if we accept or drop the patch? Do you have already defined threshold values for disk space and performance by which you will decide if it is worth to integrate mbedTLS in FFmpeg? Best regards, Thomas. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
