[FFmpeg-devel] [PATCH 2/6] sink_buffer: make opaque argument optional.

Stefano Sabatini stefasab at gmail.com
Tue Jun 26 14:06:45 CEST 2012


On date Monday 2012-06-25 00:35:56 +0200, Nicolas George encoded:
> 
> Signed-off-by: Nicolas George <nicolas.george at normalesup.org>
> ---
>  libavfilter/sink_buffer.c |   36 ++++++++++++++++++++----------------
>  1 file changed, 20 insertions(+), 16 deletions(-)
> 
> diff --git a/libavfilter/sink_buffer.c b/libavfilter/sink_buffer.c
> index c82bff0..5c85638 100644
> --- a/libavfilter/sink_buffer.c
> +++ b/libavfilter/sink_buffer.c
> @@ -243,24 +243,25 @@ static void filter_samples(AVFilterLink *link, AVFilterBufferRef *samplesref)
>  static av_cold int asink_init(AVFilterContext *ctx, const char *args, void *opaque)
>  {
>      BufferSinkContext *buf = ctx->priv;
> -    AVABufferSinkParams *params;
> +    AVABufferSinkParams *params = opaque;
>  
> -    if (!opaque) {
> -        av_log(ctx, AV_LOG_ERROR,
> -               "No opaque field provided, an AVABufferSinkParams struct is required\n");
> -        return AVERROR(EINVAL);
> -    } else
> -        params = (AVABufferSinkParams *)opaque;
> -
> -    buf->sample_fmts     = ff_copy_int_list  (params->sample_fmts);
> -    buf->channel_layouts = ff_copy_int64_list(params->channel_layouts);
> -    if (!buf->sample_fmts || !buf->channel_layouts) {
> -        av_freep(&buf->sample_fmts);
> -        av_freep(&buf->channel_layouts);
> -        return AVERROR(ENOMEM);
> +    if (params && params->sample_fmts) {
> +        buf->sample_fmts     = ff_copy_int_list  (params->sample_fmts);
> +        if (!buf->sample_fmts)
> +            goto fail_enomem;
>      }
> +    if (params && params->channel_layouts) {
> +        buf->channel_layouts = ff_copy_int64_list(params->channel_layouts);
> +        if (!buf->channel_layouts)
> +            goto fail_enomem;
> +    }

> +    if (!common_init(ctx))
> +        return 0;

Why is not propagating the error?

[...]

BTW, what's your opinion with regards to the opaque field?

The opaque field was designed to help applications which for a reason
or another needs to access a binary struct programmatically.

In case of the buffer and buffersink components they are supposed to
be used programmatically, so IMO it makes sense to keep that
interface.

The problem I was addressing with the buffersink parameter structure
was passing a *list* of formats, and I wanted to avoid all the
serialization/deserialization complications to the programmer.
-- 
FFmpeg = Formidable and Fundamentalist Merciless Prodigious Ecumenical Gargoyle


More information about the ffmpeg-devel mailing list