[libav-devel] [RFC] [PATCH] lavc: Drop exporting 2-pass encoding stats
anton at khirnov.net
Thu Dec 3 19:04:29 CET 2015
Quoting Vittorio Giovara (2015-12-03 18:55:29)
> On Thu, Dec 3, 2015 at 12:31 PM, Anton Khirnov <anton at khirnov.net> wrote:
> > 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
> > those variables.
> Oh I see what you mean, yes I was wrong.
> >> > 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.
> Rewording as follows
> These variables leaked from mpegvideoenc where are supposedly used for
"leaked"? I already said it's not statistics. And they are very
deliberately exported. One can argue that we don't want to provide this
information for whatever reason, but you cannot pretend that they are
somehow exported by accident.
> However they might very well be private
I have no idea what is this trying to say
> and, due to their
> absolute lack of documentation, they are hardly used in the wild. There is also
> a spurious frame_bits which is used in aacenc but it can be replaced
> with a simple local variable.
Are you quite sure it's spurious?
> inability to instruct applications how to use the values
What does this mean exactly?
> and the presence of better means to share this kind of information
Well, you are not using this better means.
More information about the libav-devel