[Cin] HEVC hw encoding on AMD Polaris cards
spitsyn.andrey at gmail.com
Wed May 15 07:01:09 CEST 2019
@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
ср, 15 мая 2019 г., 6:50 Phyllis Smith <phylsmith2017 at gmail.com>:
> > We tried a couple of examples of using scale_vaapi from the ffmpeg
>> > line and it always failed for us on a Intel laptop with Broadwell
>> > 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
>> 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.
> Cin mailing list
> Cin at lists.cinelerra-gg.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cin