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. Shall I just leave them there with appropriate deprecation guards? -- Vittorio _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
