[FFmpeg-devel] [PATCH] lavfi/vf_libvmaf: update to use libvmaf v1.3.9

[Carl Eugen Hoyos]

2018-08-20 7:15 GMT+02:00, Gyan Doshi <gyandoshi at gmail.com>:
> On 20-08-2018 03:17 AM, Carl Eugen Hoyos wrote:
>
>> I believe that if a general option exists (as in this case), it is a bad
>> idea to have a specifically targeted option that has to be used instead.
>
> The user may not want the thread pool to be available for any other
> threaded filters in the graph.

I wonder if this is really useful (and especially if the cost of having
an additional option for the user to know is really worth this tiny
advantage).

The more I think about it, the more it is obvious to me that 1) the
filter should use the default thread number for all filters and that 2)
an option may be specified to overwrite this number (if this is really
needed).

> Encoding/decoding threads can have stream specifiers suffixed to
> limit scope. The filter_[complex_]threads options don't.

Ok.

>>> We have -filter_complex_threads for that, so no.
>>
>> For which use-case is this an advantage?
>
> For when the intended recipient is a complex filtergraph.

For which use-case is it an advantage that there is not one
option to tell the filter-chain the number of threads to use,
no matter if it is a simple or a complex filter-chain, but to
have one option to use for the simple and a different option
for the complex case?

Carl Eugen