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

[Alexander Strasser]

On 2013-11-10 17:40 -0300, James Almer wrote:
> 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.

  It was meant to be a useful and complete utility library that is an
extension to the C standard library. But this decision was not respected
and finally undermined when the fork happened.

  To make it clear I was the one who invented lavu and created the
initial patchset that took out parts of lavc etc. that are generally
useful. Michael helped to make it ready for inclusion and also
documented that lavu is not to be used as a means to share stuff
between the remaining libav*

  There were lots of good contributions to lavu and it is a pity
that it is in such an unfortunate state now. Contributions to the
the utility side of lavu (including crypto) are still welcome by
me. Unfortunately I do not have enough time to really help out with
review and maintenance in that area. So you should be willing to
maintain your additions.


  Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131129/2489c6a0/attachment.asc>