On Thu, 2011-04-14 at 10:59 +0200, Reinhard Tartler wrote: > Breaking compatibility with released version is never a great idea.
It's questionable to what degree this is "breaking compatibility". The data formats supported by the encoder are available through the API. The application could check that and either feed data in a suitable format or at least give an error if the format list doesn't match what's expected (as opposed to producing noise). That the "ac3" encoder no longer accepts integer input could perhaps be counted as a reduction in supported features (as AFAIK there's no obvious way how existing applications could know that they're supposed to switch to "ac3_fixed" if they specifically need integer support). But it's comparable to having some subset of encoders not available in a particular library build, which applications are supposed to be able to deal with "cleanly" anyway. > What do you think about: > > - documenting this fact more prominently > - renaming the current (new) ac3 encoder to -> 'ac3_float' > - leaving the old encoder with the name 'ac3_fixed' > - deprecate using the name 'ac3', and issue a warning with av_log or > something to get application developers to explicitly choose their > encoder > > > and get this done before the next (beta) release. Likely this would at most change buggy applications from producing noise to explicitly failing. And it'd break well-behaving applications that use the name "ac3" and check what input formats that supports. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
