On Fri, Mar 8, 2024 at 12:18 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote:
> >>>>>> > >>>>>> -1: This adds avoidable runtime checks. > >>>>> > >>>>> What checks and why is that a problem? > >>>>> > >>>> It adds a runtime check to every call to ff_get_buffer() by every > >>>> decoder not supporting frame-threading (by checking whether > >>>> frame-threading is currently in use). > >>> > >>> I cannot imagine any situation where it could have a measurable impact. > >>> > >> > >> And? It is avoidable, therefore it should be avoided. > > > > Why should it be avoided when it can never have any measurable impact? > > > > The maintenance cost of a more complex API is higher than the > > infinitesimal cost of this check. > > > > What maintenance cost and complexity are you referring to? I checked and > could not find a single commit where one had to fix an ff_get_buffer() > to ff_thread_get_buffer() because it has been forgotten when the decoder > has been declared to support frame threading. > I'd wager documentation and developer complexity costs, usually a simpler API is a nice thing to have. Especially in this case, if the runtime check is minimal it doesn't make sense to keep two different APIs that do the same thing. -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".