Quoting Anton Khirnov (2020-10-29 15:01:22)
> They add considerable complexity to frame-threading implementation,
> which includes an unavoidably leaking error path, while the advantages
> of this option to the users are highly dubious.
>
> It should be always possible and desirable for the caller
They add considerable complexity to frame-threading implementation,
which includes an unavoidably leaking error path, while the advantages
of this option to the users are highly dubious.
It should be always possible and desirable for the callers to make their
get_buffer2() implementation thread-sa
Quoting Moritz Barsnick (2020-08-10 23:14:59)
> On Tue, Aug 04, 2020 at 13:59:42 +0200, Anton Khirnov wrote:
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -2883,7 +2883,9 @@ static int init_input_stream(int ist_index, char
> > *error, int error_len)
> > ist->dec_ctx->opaque
On Tue, Aug 04, 2020 at 13:59:42 +0200, Anton Khirnov wrote:
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2883,7 +2883,9 @@ static int init_input_stream(int ist_index, char
> *error, int error_len)
> ist->dec_ctx->opaque= ist;
> ist->dec_ctx->get_format
On 8/4/2020 8:59 AM, Anton Khirnov wrote:
> They add considerable complexity to frame-threading implementation,
> which includes an unavoidably leaking error path, while the advantages
> of this option to the users are highly dubious.
>
> It should be always possible and desirable for the callers
They add considerable complexity to frame-threading implementation,
which includes an unavoidably leaking error path, while the advantages
of this option to the users are highly dubious.
It should be always possible and desirable for the callers to make their
get_buffer2() implementation thread-sa
