Quoting Vittorio Giovara (2015-05-05 17:42:56) > On Tue, May 5, 2015 at 3:17 PM, Anton Khirnov <[email protected]> wrote: > > Quoting Vittorio Giovara (2015-05-05 15:17:39) > >> On Sat, May 2, 2015 at 5:39 AM, Anton Khirnov <[email protected]> wrote: > >> > Quoting Vittorio Giovara (2015-05-02 01:17:09) > >> >> This field is used only to report compression statistics, setting any > >> >> other field is unsupported. > >> >> > >> >> Rather than setting random properties in this field, use or add > >> >> alternative values from either context or input frame. > >> >> > >> >> Do not overwrite its pointer, and do not fill it twice. > >> >> > >> >> Signed-off-by: Vittorio Giovara <[email protected]> > >> >> --- > >> > > >> > I'm ambiguous about this patch, it seems to me it does too many things > >> > at once and the justification in the commit message is very > >> > vague/handwavy. > >> > > >> > You cannot just drop things that might still be used by people without a > >> > good reason, a proper replacement and a deprecation period, even if the > >> > API is insane. > >> > >> The problem is that there was no definite way of handling this, eg > >> some encoders would set completely random fields. It's not a matter of > >> insanity, but rather being unpredictable and thus unusable from the > >> api user. > > > > Just the fact that it's unpredictable does not mean it is unusable. Some > > people might rely on the fact that some encoders set this information, > > we should not break this without a very good reason. > > So what would you suggest? I don't really want to add fields in > avstats (or however it ends up) that not only do not belong to the > stats/properties section, but are already available to the caller.
Of course. I'm absolutely not saying you should do anything of the sort. > Shall I just leave them there with appropriate deprecation guards? Yes, that should be enough in most of those cases. Since coded_frame will get deprecated later, any users of those fields will get the appropriate deprecation warnings and will have a chance to adapt their code. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
