[FFmpeg-devel] [PATCH] lavr: deprecate the entire library

James Almer jamrial at gmail.com
Fri Nov 17 19:53:29 EET 2017


On 11/17/2017 12:58 PM, Rostislav Pehlivanov wrote:
> Signed-off-by: Rostislav Pehlivanov <atomnuker at gmail.com>
> ---
>  doc/APIchanges        | 5 +++++
>  libavresample/utils.c | 3 +++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index d336f6ce22..22c7b5a0d0 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,11 @@ libavutil:     2017-10-21
>  
>  API changes, most recent first:
>  
> +2017-xx-xx - xxxxxxx - lavr 4.0.0 - avresample.h
> +  Deprecate the entire library. It was unmaintained and redundant> +  as libswresample did everything it did better, faster, with more
> +  control and with a better, slightly higher level API.

This is only partly true. For example, last time i checked swr is
missing some multichannel simd optimizations available on lavr.

> +
>  2017-xx-xx - xxxxxxx - lavc 58.3.100 - avcodec.h
>    Add avcodec_get_hw_frames_parameters().
>  
> diff --git a/libavresample/utils.c b/libavresample/utils.c
> index b4fb906556..3e629fe901 100644
> --- a/libavresample/utils.c
> +++ b/libavresample/utils.c
> @@ -37,6 +37,9 @@ int avresample_open(AVAudioResampleContext *avr)
>  {
>      int ret;
>  
> +    av_log(avr, AV_LOG_WARNING, "This library is being deprecated in favor of libswresample, "
> +           "please migrate your program.");
> +
>      if (avresample_is_open(avr)) {
>          av_log(avr, AV_LOG_ERROR, "The resampling context is already open.\n");
>          return AVERROR(EINVAL);
> 

I don't like this patch much. It gives the same bad vibes as the
"deprecated" ffmpeg package in debian from five years ago. Lets try to
not go there again.

In any case, lavr is disabled by default, ffmpeg requires swr, opusdec
requires swr, etc. So the only people using lavr are those that
purposely want their codebase to work with both projects even if in a
handicapped way, and are thus unlikely to consider/bother to migrate to swr.
People that only care about ffmpeg already use swr because of the above
reasons.

If others however support/endorse this patch or a similar one then I'll
not block it.


More information about the ffmpeg-devel mailing list