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

[Thierry Foucu]

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)

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.

>
> I remember that last year, there was an extractqp for h264 patches from
> Google, for example.
>
> Any other question is basically less important.
>
> If that is useful, then, we should update the API and remove the old API.
> If it is not, then, let's remove everything.
>
> Best,
>
> --
> Jean-Baptiste Kempf -  President
> +33 672 704 734
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".



-- 

Thierry Foucu