On 8/20/18, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > 2018-08-20 7:15 GMT+02:00, Gyan Doshi <gyando...@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).
Both cases are already present. Please learn to read and understand documentation. > >> 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? Again, there is already option, please consult documentation. This filter does not use lavfi threads so it should not use lavfi threads option. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
