[FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp

[Anton Khirnov]

Quoting Thierry Foucu (2020-02-26 19:04:57)
> First of all, thanks for trying to clean up deprecated API
> 
> On Wed, Feb 26, 2020 at 6:03 AM Jean-Baptiste Kempf <jb at videolan.org> wrote:
> 
> > Yo,
> >
> > On Wed, Feb 26, 2020, at 14:27, Thilo Borgmann wrote:
> > > > The patch in your link is not using this API. Precisely because this
> > API
> > > > is inadequate for anything newer than MPEG4 ASP. If anything, it's an
> > > > additional argument in favor of my patches.
> > >
> > > My actual point about that patch was that there is a use case to
> > > extract QP tables for more current codecs. Suggests this use case is
> > > also there for less current ones which says we should not just remove
> > > this possibility.
> >
> > I think this is the right question:
> > "Are there actual valid use cases to do it?"
> >
> 
> yes, there is a use case for extracting QP per block:
> To analyze and visualize QP to validate/analyze Rate Control when we enable
> Adaptive QP and ROI for example.
> Most people who works on Rate Control know that the choice of the right
> MV/QP/block type is really important for quality.
> In today world, you will have to license existing software to visualize the
> QP, but if you want to do this over +10k video, and analyze QP based on
> some stats we expect to have, you need some libraries to do it.
> People could write some codec parser to extract the QP per block, but this
> is almost re-implementing part of libavcodec.
> Today, for example, when we want to visualize QP, we use libavcodec to
> decode the frame, use another piece of code to extract the QP and overlay
> both of them. This is almost (and i say ALMOST) decoding the frame twice.
> (BTW, we can do that already with libavcodec for MV, so why not for QP)

Thank you, finally there is a clear use case.

> 
> Last summer, an intern from google tried to come up with a metadata
> structure to store information per block.
> This would have allow to store per block, the MV, QP, block type, etc.. And
> it could have work for any codec with any different block size.
> He was trying to implement what was done for MV and replace the QP with
> this new metadata.
> 
> I agree that the current QP code (not feature) should be deprecated as it
> does not work with newer codec.
> But before removing the deprecated code, it will be nice to have the same
> feature available with a newer API, so the features of
> extracting/analyzing/overlaying QP still work.

Yes, it does indeed sound reasonable to push this new API and convert
the old code to it. The question remains if any of the people arguing
for keeping those filters are also willing to do the conversion.

-- 
Anton Khirnov