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

Michael Niedermayer michaelni at gmx.at
Thu Feb 27 19:33:56 EET 2020


On Thu, Feb 27, 2020 at 12:30:22PM +0100, Anton Khirnov wrote:
> 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.

I am willing to help, the time ATM is not great though because theres
alot i want/need to do both related to FFmpeg and unrelated.
(for example iam behind with making a new release which should happen
 before the bump ...)

so i suspect by the time i get around to look into qp API updating
someone else probably will already have done it ...

Thanks

 [...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200227/f7736c39/attachment.sig>


More information about the ffmpeg-devel mailing list