[libav-devel] [RFC] [PATCH] lavc: Drop exporting 2-pass encoding stats
anton at khirnov.net
Thu Dec 3 18:31:17 CET 2015
Quoting Vittorio Giovara (2015-12-03 17:53:12)
> On Thu, Dec 3, 2015 at 3:48 AM, Anton Khirnov <anton at khirnov.net> wrote:
> > Quoting Vittorio Giovara (2015-11-30 18:19:36)
> >> These variables leaked from mpegvideoenc where are supposedly used for
> >> statistics. However they might very well be private, and, due to their
> >> absolute lack of documentation, they are hardly used in the wild. Despite
> >> being write-only there are options to initalize them, without any effect.
> >> There is spurious frame_bits which is used in aacenc, again in
> >> write-only mode, where it can be replaced with a simple local variable.
> >> Due to the extremely limited scope of use, inability to instruct
> >> applications how to use the values, and the presence of better means
> >> to share this kind of information (for example AV_PKT_DATA_QUALITY_FACTOR)
> >> these fields are removed from the global context.
> > I'm generally fine with deprecating those things, but I don't like the
> > motivation described here.
> > You mention twice that they are "write-only" as if it was in some way a
> > problem. It's not! The entire point of those variables is to export
> > information to the caller. It's perfectly natural that they are
> > write-only for the codec.
> I was mostly referring to the fact that in addition to being write
> only there are options that initialize them (and do nothing)
The options are for reading, not writing them. Besides, I don't see how
the fact that some options exist is in any way an argument for removing
> > Also, AV_PKT_DATA_QUALITY_FACTOR is really no replacement for this, so
> > mentioning it as a "better means" is misleading.
> it's one of various mean that could be used to report statistics, but
> yeah it could be misleading.
"statistics". You keep using that word.
First, neither the stuff you're deprecating, nor the quality factor are
"statistics", as they are all local per-frame information.
Second, the fact that they both describe the coded frame properties in
some way does not at all mean that one is a replacement for the other.
More information about the libav-devel