[FFmpeg-devel] scaling option

[Yufei He]

On 03/26/2019 02:36 PM, Dennis Mungai wrote:


On Tue, Mar 26, 2019, 21:20 Yufei He <yhe at matrox.com<mailto: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<mailto: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.