‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, 26 de November de 2018 14:00, Micael Silva <micaelsilva at gmail.com> wrote:
> On Mon, Nov 26, 2018 at 7:47 AM msanders marksanders at protonmail.com wrote:
>> > Hi,
> > As now we have many filters compatible with the GPU, and in particular
> > “scale” filters. So I think we need a filter like “hwoverlay” or
> > “overlay_cuda/_qsv/etc.”.
> > With this kind of filter we can do a PiP using only a GPU pipeline:
> >
> > - GPU decoder --> spplit (hw) --> hwscale --> hwoverlay --> GPU encoder
> >
> > In fact, I feel it’s not too complex to do.
> > What you think?
> > M. Sanders
>> It's a good idea, although working with hardware accelerators it's never so
> straightforward. It depends how that API is construct, what methods are
> allowed, and many bugs and crashes surface. Hardware processing is less
> flexible in many aspects.
>> Maybe possible, but I think that requiring more specialized people may take
> more time to realize
>Hi,
The complexity varies.
- If the implementation is "generic", for example using some function like "av_frame_clone()" that works with RAM and GPU frames, then it will be more complex... at start. In this case new functions "av_frame_clip()" and "av_frame_overlay()" should be required.
- And if the implementation is "particular", for example implementing "overlay_cuda|_qsv", then it will be more simple.
In fact, using the code of "vf_scale_cuda.c" can be easy to translate it to a "vf_overlay_cuda.c". The reason it's because the GPU copy functions are already implemented. And the algorithm is summarized in: copy the complete frame and then overwrite with the small frame. So, only "copy GPU" functions are required.
Anyone interested?