[FFmpeg-devel] [PATCH][FFmpeg-devel v2] Add GPU accelerated video crop filter

[Timo Rothenpieler]

On 25/03/2019 09:27, Tao Zhang wrote:
>>> Hi,
>>>
>>> Timo and Mark and I have been discussing this, and we think the right
>>> thing to do is add support to vf_scale_cuda to respect the crop
>>> properties on an input AVFrame. Mark posted a patch to vf_crop to
>>> ensure that the properties are set, and then the scale filter should
>>> respect those properties if they are set. You can look at
>>> vf_scale_vaapi for how the properties are read, but they will require
>>> explicit handling to adjust the src dimensions passed to the scale
>>> filter.
> Maybe a little not intuitive to users.
>>>
>>> This will be a more efficient way of handling crops, in terms of total
>>> lines of code and also allowing crop/scale with one less copy.
>>>
>>> I know this is quite different from the approach you've taken here, and
>>> we appreciate the work you've done, but it should be better overall to
>>> implement this integrated method.
>> Hi Philip,
>>
>> Glad to hear you guys had discussion on this. As I am also considering the problem, I have some questions about your idea.
>> So, what if user did not insert a scale_cuda after crop filter? Do you plan to automatically insert scale_cuda or just ignore the crop?
>> What if user want to do crop,transpose_cuda,scale_cuda? So we also need to handle crop inside transpose_cuda filter?
 >
> I have the same question.
Ideally, scale_cuda should be auto-inserted at the required places once 
it works that way.
Otherwise it seems pointless to me if the user still has to manually 
insert it after the generic filters setting metadata.

For that reason it should also still support getting its parameters 
passed directly as a fallback, and potentially even expose multiple 
filter names, so crop_cuda and transpose_cuda are still visible, but 
ultimately point to the same filter code.

We have a transpose_npp, right now, but with libnpp slowly being on its 
way out, transpose_cuda is needed, and ultimately even a format_cuda 
filter, since right now scale_npp is the only filter that can convert 
pixel formats on the hardware.
I'd also like to see scale_cuda to support a few more interpolation 
algorithms, but that's not very important for now.

All this functionality can be in the same filter, which is scale_cuda. 
The point of that is that it avoids needless expensive frame copies as 
much as possible.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4538 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190325/77a15855/attachment.bin>