Quoting wm4 (2016-03-04 10:48:27) > On Fri, 04 Mar 2016 08:27:54 +0100 > Anton Khirnov <[email protected]> wrote: > > > Quoting Hendrik Leppkes (2016-02-26 10:53:24) > > > On Thu, Feb 25, 2016 at 4:05 PM, Anton Khirnov <[email protected]> wrote: > > > > > > > Deprecate the current bitstream filtering API. > > > > +/** > > > > + * Iterate over all registered bitstream filters. > > > > + * > > > > + * @param opaque a pointer where libavcodec will store the iteration > > > > state. Must > > > > + * point to NULL to start the iteration. > > > > + * > > > > + * @return the next registered bitstream filter or NULL when the > > > > iteration is > > > > + * finished > > > > + */ > > > > +const AVBitStreamFilter *av_bsf_next(void **opaque); > > > > > > Other iteration functions we have just take the return from the > > > previous call as a "state" (ie. the previous BSF in this case), that > > > seems much more sensible than some weird ptr-ptr-opaque value. > > > Keeping it in line with existing API would be a big bonus (ie. just > > > like av_bitstream_filter_next worked). > > > > > > > The problem is that unlike the other APIs, the bsfs are stored in an > > array instead of a linked list (to avoid global registration). So an API > > like you want would have quadratic complexity instead of linear. It's > > probably not a big deal, since we're unlikely to have hundreds of bsfs, > > but it feels ugly. > > > > And you want to change that later again? Hiding the implementation > details seems like a good idea in any case, but this feels a bit > awkward.
Change what later? -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
