On Mon, 23 Apr 2018 21:09:09 +0200 Thomas Volkert <si...@gmx.net> wrote:
> On 23.04.2018 14:08, Rostislav Pehlivanov wrote: > > On 23 April 2018 at 10:27, Thomas Volkert <si...@gmx.net> 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. > >> > >> Best regards, > >> Thomas. > >> _______________________________________________ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > > I'd like some memory usage and performance comparisons to gnutls and > > The mbedTLS library uses less than half of the disc space compared to > OpenSSL in this context. > I don't have exact figures for memory consumption for different > scenarios right now. > > > > openssl before you push. This is the 6th (!!) TLS library we'd be > > supporting. > > Two of the existing ones are OS specific. > > In general, I see mbedTLS as an enrichment for FFmpeg. MbedTLS seems to > be a promising alternative to OpenSSL and other TLS implementations in > the context of embedded systems: the disk footprint is smaller out of > the box, the memory footprint is smaller, the library is intentionally > modular so that these can be reduced further at need > (https://tls.mbed.org/tiny-ssl-library, > https://tls.mbed.org/kb/how-to/reduce-mbedtls-memory-and-storage-footprint). > > Additionally, in the planned context the mbedTLS library is already used > for signaling out-of-band control messages between network peers. And it > is planned to do some more tuning to the overall setup to get an even > smaller version of mbedTLS on the target device. To be honest that's not really convincing. How does it compare with e.g. libtls? In my opinion it's probably not wrong to give another TLS lib a try, but: 1. It was kind of too early. You should at least have given us some time to respond. 2. Having many TLS wrappers is actually not a good thing because it will confuse users about which one to pick, and the wrappers will all have subtly different behavior that can become a problem for ffmpeg and libav* users. 3. It's hard to remove redundant things even after it has turned out that they were not that useful. (See e.g. how much effort it was to remove some of the virtually useless codec lib wrappers.) But it's just my opinion that having fewer well maintained choices is better than many with maintenance deficits. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
