[FFmpeg-devel] scaling option

Dennis Mungai dmngaie at gmail.com
Tue Mar 26 20:36:59 EET 2019


On Tue, Mar 26, 2019, 21:20 Yufei He <yhe at matrox.com> wrote:

> On 03/26/2019 11:31 AM, Dennis Mungai wrote:
> > On Tue, 26 Mar 2019 at 18:21, Yufei He <yhe at matrox.com> wrote:
> >
> >> On 03/26/2019 08:53 AM, Timo Rothenpieler wrote:
> >> On 26/03/2019 13:47, Yufei He wrote:
> >> Hi
> >>
> >> Is there option for scaling on transcoding ?
> >>
> >> e.g. transcoding from a quadhd file to 640 * 480.
> >>
> >> Thanks.
> >>
> >> Yufei.
> >>
> >>
> >> Yes there is, but this is ffmpeg-devel, so not the place to ask user
> >> questions.
> >>
> >> Yes, I see the option of -vf scale=width:height
> >> We can do scaling on decoding or encoding, my question was to check if
> >> there is scaling option for codec.
> >> I'll add special scaling option to our codec.
> >>
> >>
> > Hello there,
> >
> > Scaling comes in two forms (correct me if I'm wrong):
> >
> > 1. Specific video filters, such as the scale filters, and other
> > hardware-accelerated implementations, such as scale_npp, scale_cuda,
> > scale_vaapi, etc.
> > 2. Decoders (Not too sure if equating the private -resize option provided
> > by these decoders is equivalent to "scaling"):
> >
> > See the example provided by the likes of the cuvid implementations, such
> as
> > h264_cuvid, etc:
> >
> > ffmpeg -h decoder=h264_cuvid
> >
> > The -resize option therein acts as a scaler.
> >
> > Are you planning to implement a codec-specific hardware (or
> software-based)
> > scaler (implemented as a video filter or a decoder), with similar
> > functionality?
> Hi Dennis
> Our hardware m264 supports scaling and encoding or decoding at the same
> time, this saves memory copy time between host and card if it's scaled
> in host or in other separate filter.
> I'm trying to make it work in FFmpeg.
>
> Yufei.
>


Here's what you'll need to implement:

1. A hwaccel of the type equivalent to the accelerator backend you're
creating, and

2. The actual hwaccel implementation. This will be an encoder (or set of
encoders) targeting the codecs you're after.

3. Based on the two above, create video filters that can take advantage of
hwupload, hwdownload, etc to create filter chains that will allow to move
(and map) textures, etc from system to device memory . Take a look at how
CUDA based hwaccels are implemented. That's a good crash course on what
needs to be done.

4. Understand how the FFmpeg development process works. Patches are
welcome, but the review process and adherence to coding standards matters
even more. See the wikis on what's expected regarding the development
process. I'd suggest being aware of the subsystem maintainers and the roles
they play.

5. On vendor specific libraries: I'd suggest releasing this as an open
implementation such that it can be hosted in a manner similar to how the
ffnvcodec headers are handled. Trust me, you'll greatly lower the
maintainance overhead on time.

Hope that helps.

>


More information about the ffmpeg-devel mailing list