[Cin] HEVC hw encoding on AMD Polaris cards

[Андрей Спицын]

@GG  My hardware is little bit outdated so I already using script for a
proxy files creation. I've spend some time to find appropriate options for
ffmpeg to use fully hardware encoding/filtering. It has very good results
compared to cinelerra proxy routine (about 30x faster) and cinelerra using
ffmpeg's hardware filter and vaapi encoder (around 10x faster).
So I thought that cinelerra can use this script to speed up the proxy files
creation.


ср, 15 мая 2019 г., 6:50 Phyllis Smith <phylsmith2017 at gmail.com>:

>
> > We tried a couple of examples of using scale_vaapi  from the ffmpeg
>> command
>> > line and it always failed for us on a Intel laptop with Broadwell
>> graphics
>> > board.  For example, something like the following:
>> >
>> > ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i input.mp4 -vf
>> > 'scale_vaapi=1280:720'.. out.mp4
>>
>> It seems correct line (at least for intel) include a bit more than just
>> scale_vaapi:
>>
>> https://xtechbiz.com/intel-vaapi-encoding-ubuntu-17-10/
>>
>> Using the vaapi_scaler in the video filters : It is possible to use
>> Intel’s QuickSync hardware via VAAPI for resize and scaling (when up-or
>> downscaling the input source to a higher or lower resolution), using a
>> filter snippet such as the one shown below:
>> -vf 'format=nv12,hwupload,scale_vaapi=w=1920:h=1080'
>> You may specify a different resolution by changing the dimensions in =w=
>> and :h= to suit your needs.
>>
>>  Thanks for the URL, it was illustrative ... and now GG is typing ...
>
> this strategy uses a "complex filter graph" for the video data path .
> cin5 only does simple filters on the "input pads" via the video_filter=
> keyword in the decode opts file.  This seems to be a "complex graph" on the
> output path.  When you use ffmpeg filters in cin5, the normal filter stack
> is done using the ffmpeg "plugins".  They are really ffmpeg filters that
> have been glued into the cin5 plugin stack, not into a filter graph.  There
> has been no demand (until now) for a output filter chain.  It is probably
> not impossible to write code for it, but it is not clear why you would use
> this and not just drop a plugin on the stack to scale the data.  There may
> be a speed gain, but it would have to be pretty attractive before it would
> be worth adding an output filter graph interface to the ffmpeg encode data
> path.  This method of  scaling is not very flexible.  The only way I can
> see that it would be worth it, is that you intend to encode months of video
> data, and the hardware would improve the rate of encoding enough to offset
> the software development  time.
>
> gg
>
>
>
> --
> Cin mailing list
> Cin at lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20190515/5779559f/attachment.html>