[FFmpeg-devel] scaling option

[Dennis Mungai]

On Wed, 27 Mar 2019 at 17:51, Yufei He <yhe at matrox.com> wrote:

> On 03/26/2019 02:36 PM, Dennis Mungai wrote:
>
>
>
> 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.
>
> Hi Dennis
>
> We will talk about your suggestion and schedule it later.
>
> Thanks for your help.
>
> Yufei.
>

And I'll issue a warning, before it blocks this patch from going anywhere:
Do *NOT* link to a library bundled within the device driver.
There's no (justifiable) reason for that. Also see the note on maintainer
overhead above.
Avail the shim (intermediate library) as recommended above such that it can
be enabled at ./configure as an option.
The end user should be able to compile and install the aforementioned
library to a pre-configured prefix, such that when building FFmpeg, the
same facility can pick up that library and enable the requested
component(s) as per the directive(s) in ./configure.
What your (now rejected) patch in the mailing list does shifts the burden
of maintaining ABI compatibility to a *device driver component* and until
that's resolved, it will go nowhere.