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 <j...@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.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".