[FFmpeg-devel] [PATCH 8/9] avfilter/scale_amf: Add AMF HW scaler & color converter

[Dennis Mungai]

On Mon, 19 Feb 2024, 14:18 Evgeny Pavlov, <lucenticus at gmail.com> wrote:

> On Wed, Feb 14, 2024 at 5:26 PM Dennis Mungai <dmngaie at gmail.com> wrote:
>
> > On Wed, 14 Feb 2024, 18:28 Evgeny Pavlov, <lucenticus at gmail.com> wrote:
> >
> > > On Wed, Feb 14, 2024 at 4:08 PM Timo Rothenpieler <
> timo at rothenpieler.org
> > >
> > > wrote:
> > >
> > > > On 14/02/2024 02:55, Dmitrii Ovchinnikov wrote:
> > > > > From: Evgeny Pavlov <lucenticus at gmail.com>
> > > > >
> > > > > This commit adds two AMF filters: scale_amf & scale_amf_hq.
> > > > > Both filters are using AMF hardware acceleration.
> > > > > scale_amf supports simple scaling algorithms & color conversion.
> > > > > scale_amf_hq supports advanced scaling algorithms & might be used
> > > > > for upscaling only.
> > > >
> > > > Haven't looked at the patch yet, but can't this be one filter, and it
> > > > picks the best possible method depending on options/inputs/whatever?
> > > > _______________________________________________
> > > > 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".
> > > >
> > >
> > > AMF has 2 separate components for color conversion + simple scaling
> > > (VideoConverter)  and for advanced scaling (HQScaler).
> > > We've got a recommendation from the AMD AMF team to implement these
> > > components as separate ffmpeg filters.
> > >
> >
> >
> > Still, this should be a single VIdeo Post-Processing (VPP) -style filter,
> > exposing these scaling and video post processing options as tunables
> > therein.
> >
> > A perfect example of such an implementation that excels in such an
> > abstraction is intel's vpp_qsv filter, from which multiple compute, color
> > space conversion methods, tonemapping, etc are made available through
> > tunables.
> >
> > Another benefit of such an abstraction would be that re-using this filter
> > on other GPU derivatives of the discrete silicon, eg in smaller IGPs
> > sharing these offload blocks would be auto-detecting logic to ensure that
> > even with defaults, the filter chains run.
> >
> > Taking another example from Intel, they have a full H/W path for low
> power
> > encode and Post-Processing that can be automatically toggled on by
> specific
> > filter options without user intervention, guaranteeing runtime safety for
> > the same command(s) even on newer GPUs.
> >
> > Food for thought.
> >
> > >
> > _______________________________________________
> > 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".
> >
>
> AMF Video Converter (which is used in scale_amf) is the full analog of
> Intel's VPP. And in the future, it may have an option for dedicated HW
> block in GPU. It has scaling, color conversion, tonemapping, HDR <> SDR
> conversion features.
> But HQ Scaler brings advanced scaling algorithms that are similar to AMD
> FSR (https://www.amd.com/en/technologies/fidelityfx-super-resolution ) and
> don’t have color conversion and cannot be mapped to HW blocks.
> Do you think that it would be better to rename scale_amf to vpp_amf or some
> other name? Maybe we should rename scale_amf_hq as well for better
> usability (e.g. sr_amf)?
>


Evgeny,

That's an excellent proposal.

With the renaming of scale_amf to vpp_amf and the extra filter abstracting
FSR style upscaling stuff to sr_amf,  it becomes absolutely clear what each
filter is meant to accomplish.

>