@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 <phylsmith2...@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@lists.cinelerra-gg.org > https://lists.cinelerra-gg.org/mailman/listinfo/cin >
-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin