[FFmpeg-devel] [PATCH 5/5] doc: remove avutil.txt

[James Almer]

On 10/11/13 5:28 PM, Stefano Sabatini wrote:
> On date Sunday 2013-11-10 16:56:04 -0300, James Almer encoded:
>> On 10/11/13 8:48 AM, Stefano Sabatini wrote:
>>> I don't know if we should move this (and the "It is not a library for
>>> code needed by both libavcodec and libavformat" thing) to
>>> libavutil.texi.
>>>
>>
>> Regarding the "It is not a library for code needed by both libavcodec and 
>> libavformat", how true is that in general? What's people opinion?
>>
>> I have so far contributed with RIPEMD and SHA-2 512 modules that, while 
>> certainly useful in many situations, they seemingly aren't so in multimedia. 
>> No format or protocol ever seems to use anything but CRC32, MD5 or SHA-1.
>>
> 
>> I ask because i have written several other crypto modules (MD4, CRC64, Tiger 
>> and Whirlpool, all available in my github repo) that i haven't yet submitted 
>> for reviewing because i wasn't sure they were worth the maintenance burden 
>> if no format or protocol would ever give them any use.
>> If lavu's purpose is being a feature complete utility library (or as complete
>> as possible at least) meant to be used in any kind of project, then I'll post 
>> them here.
> 
> Different developers have different opinions, as to what we should
> consider lavu for. In the end is the module maintainer who decides in
> this case.
> 
> OTOH it would be useful to know what's your specific use case, and why
> you can't use for example a more generic library for achieving the
> same purpose.

I wrote them with no other purpose than making lavu's crypto portion as feature 
complete as possible, hopefully on par with tomcrypt or openssl's crypto in the 
long run.
Stopped after RIPEMD and SHA-2 512 since i realized that maybe lavu wasn't meant 
to be like that, or even used like that for that matter. Hence me asking this now.

> About the "smallness" thing, we agreed that allowing conditional
> compilation of the required submodules would be useful for various
> reasons (e.g. to decrease binary size), but this was never
> implemented.

I've seen at least one project manually disabling modules they didn't need.
Implementing this in the build system would certainly make some people's lives 
easier.

Regards.