Not sure if I send this bunch of links to list or only to my friend... Few days ago I compiled Cin-GG snapshot from git for my friend with AMD machine (AMD phenom x4 as cpu, and RX470 as GPU). Initially hw decoding/encoding was not working for him, but after some tries he was able to set Cin-GG to 'vdpau decode, vaapi h264 encode" and this mdoe worked, while not ultrafast. Still, I was puzzled at his vainfo: vainfo: VA-API version: 1.4 (libva 2.4.0) vainfo: Driver version: Mesa Gallium driver 18.3.6 for AMD Radeon (TM) RX 470 Graphics (POLARIS10, DRM 3.8.0, 4.9.155-nrj-desktop-1rosa-x86_64, LLVM 7.0.1) vainfo: Supported profile and entrypoints EE ../src/gallium/drivers/radeonsi/si_get.c:642 si_get_video_param UVD - No MJPEG support for the kernel version VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc No HEVC encoding, as you can see! After some digging I found possible reason - too old kernel! https://www.phoronix.com/scan.php?page=news_item&px=UVD-H265-HEVC-Encode-In-... ---------------- Written by Michael Larabel in Radeon on 24 February 2018 at 03:09 PM EST. 14 Comments RADEON Earlier this month AMD developers landed VCN-powered video encode support for the HEVC main format while now this has come to the UVD engine so it will work with pre-Raven GPUs. VCN "Video Core Next" is the new unified video encode/decode block found so far just on Raven Ridge APUs. That VCN support has been getting into Mesa while AMD's James Zhu this week enabled UVD-based encode for the HEVC main profile. The patches had been floating around on the Mesa mailing list for a few weeks but have now been merged and flipped on for those interested in GPU-based HEVC/H.265 main profile encoding using the UVD block. Hardware-wise, it appears this implementation should work with Carrizo APUs. Fiji GPUs and newer. If you try it out, make sure you are also using the latest firmware files for your GPU. These Mesa changes will be present for next quarter's Mesa 18.1 release along with a whole lot more for advancing the open-source Radeon Linux graphics driver stack. ---------------- https://lists.freedesktop.org/archives/amd-gfx/2017-October/013939.html https://cgit.freedesktop.org/mesa/mesa/log/?qt=grep&q=uvd+hevc https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=v5... -------------- 2017-10-09 Merge branch 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux int... Dave Airlie 88 -22439/+6754 2017-10-06 drm/amdgpu: add uvd enc irq James Zhu 1 -2/+38 2017-10-06 drm/amdgpu: add uvd enc ib test James Zhu 1 -0/+172 2017-10-06 drm/amdgpu: add uvd enc ring test James Zhu 1 -1/+54 2017-10-06 drm/amdgpu: add uvd enc vm functions (v2) James Zhu 1 -2/+44 2017-10-06 drm/amdgpu: add uvd enc into run queue James Zhu 1 -0/+14 2017-10-06 drm/amdgpu: add uvd enc rings James Zhu 1 -2/+52 2017-10-06 drm/amdgpu: add new uvd enc ring methods James Zhu 1 -0/+117 2017-10-06 drm/amdgpu: add uvd enc command in header James Zhu 1 -0/+10 2017-10-06 drm/amdgpu: add uvd enc registers in header ------------------- so, it seems you need kernel 4.15 + mesa 18.1+ and also probably new enough firmware.... https://www.x.org/wiki/RadeonFeature/#index8h2 ============ + some windows tests from 2016: https://forum.videohelp.com/threads/380081-AMD-Polaris-(Radeon-RX-4xx)-H265-... + some ffmpeg-users correspondence from 2018: https://ffmpeg.org/pipermail/ffmpeg-user/2018-July/040681.html [FFmpeg-user] Using a AMD Radeon RX5xx with ffmpeg In theory, hevc encoder on Polaris should be faster than h264, but not very good at high bit rates (from forum link at videohelp). Some speed figures for VCE 3.4: https://github.com/obsproject/obs-amd-encoder/wiki/Hardware-Support#video-co... https://github.com/obsproject/obs-amd-encoder/wiki/Hardware-VCE3.4 Hardware VCE3.4 Jump to bottom Michael Fabian Dirks edited this page May 6, 2017 · 21 revisions Version 3.4 added support for H265/HEVC encoding at the cost of reduced throughput in H264/AVC and H264/SVC encoding and also losing the ability to encode B-Frames. Capabilities Acceleration: Hardware Profiles: High, Main, Baseline Maximum Level: 5.2 B-Pictures Supported: No Maximum Simultaneous Streams: 16 Input Resolution: 64x64 - 4096x2160 Formats: NV12, YUV420P, YV12, BGRA, RGBA, ARGB Memory Types: DX11, OpenCL, OpenGL, Host Interlaced Supported: No Output Resolution: 64x64 - 4096x2160 Formats: NV12 Memory Types: DX11, OpenCL, OpenGL, Host Interlaced Supported: No Limits All FPS values are to be read as "up to <x> FPS". There are no guarantees that you will achieve this value. RX 460 RX 470 RX 480 RX 460 Resolution Speed Balanced Quality 160x120 2871 FPS 2723 FPS 2356 FPS 240x160 2457 FPS 2237 FPS 1762 FPS 256x160 2431 FPS 2186 FPS 1705 FPS 320x240 1864 FPS 1605 FPS 1134 FPS 480x320 1269 FPS 1037 FPS 651 FPS 640x460 790 FPS 613 FPS 361 FPS 640x480 767 FPS 595 FPS 349 FPS 800x600 519 FPS 400 FPS 229 FPS 854x480 525 FPS 454 FPS 272 FPS 960x540 490 FPS 376 FPS 215 FPS 1024x768 342 FPS 259 FPS 146 FPS 1152x864 276 FPS 209 FPS 116 FPS 1280x720 297 FPS 224 FPS 125 FPS 1280x800 269 FPS 203 FPS 113 FPS 1280x1024 217 FPS 162 FPS 89 FPS 1366x768 261 FPS 199 FPS 111 FPS 1440x900 216 FPS 162 FPS 89 FPS 1600x1200 152 FPS 113 FPS 61 FPS 1920x1080 140 FPS 104 FPS 56 FPS 1920x1200 128 FPS 95 FPS 51 FPS 1920x1440 107 FPS 79 FPS 43 FPS 1920x1920 81 FPS 60 FPS 32 FPS 2048x1080 132 FPS 98 FPS 53 FPS 2560x1440 81 FPS 60 FPS 32 FPS 3440x1440 61 FPS 45 FPS 24 FPS 3840x2160 36 FPS 27 FPS 18 FPS 4096x2160 34 FPS 25 FPS 17 FPS and two more tables below this one
Hi Andrew, I have a PC with Polaris AMD card (rx550). As I wrote earlier in neighbor thread I managed to get work vaapi decoding on that card. My card capable of decode HEVC decoding, but hw encoding h264 (and probably HEVC) is problem due to unsupported B-frames in driver or hardware. If you create static build for debian 9 I can test hw encoding with my card.
В сообщении от Monday 13 May 2019 14:01:03 Андрей Спицын написал(а):
Hi Andrew,
I have a PC with Polaris AMD card (rx550). As I wrote earlier in neighbor thread I managed to get work vaapi decoding on that card. My card capable of decode HEVC decoding, but hw encoding h264 (and probably HEVC) is problem due to unsupported B-frames in driver or hardware.
If you create static build for debian 9 I can test hw encoding with my card.
You mean for debian 9 x86-64 ?
В сообщении от Monday 13 May 2019 15:12:14 Андрей Спицын написал(а):
You mean for debian 9 x86-64 ?
Yes.
Currently compiling. Cinelerra-GG's configure complained about old nasm, so software x264 encoding will be slow .... I tried to add debian-backports to /etc/apt/sources.list, they have new-ish kernel 4.19 but no new nasm!
Currently compiling.
Oh, thank you!
I tried to add debian-backports to /etc/apt/sources.list, they have new-ish kernel 4.19 but no new nasm! More over, current debian stable has ffmpeg incompatible with -bf 0 option needed for Polaris cards! So no hw encoding on debian's ffmpeg.
В сообщении от Monday 13 May 2019 20:56:26 Спицын Андрей написал(а):
Currently compiling.
Oh, thank you!
I tried to add debian-backports to /etc/apt/sources.list, they have new-ish kernel 4.19 but no new nasm! More over, current debian stable has ffmpeg incompatible with -bf 0 option needed for Polaris cards! So no hw encoding on debian's ffmpeg.
Yeah, and mesa was too old for my tastes (13.0.6 ?). Still, in theory backports should have mesa 18.2.x , just not tried installing it on qemu VM. https://cloud.mail.ru/public/2SM5/2x3DPD4sU in theory, there should be cinelerra-gg compiled from today's git _with_ thirdparty ffmpeg/x264/x265 Also, I tried to rebuild nams package vai pbuilder from Ubuntu files. Result in same folder.
Hi Andrew, Here the quick test results. I used 4k sample video on my PC with RX550 and outdated CPU (ten years-old double-core Pentium) The variable CIN_HW_DEV affects only on ability to play videos. My test video with vaapi device plays at full speed with around 50% CPU load. The use of 'none' device results in unplayable video (more like slide show). But in both cases I can successfully encode video with hevc_vaapi and h264_vaapi (profile=main) encoders with about 100% CPU load. The hevc encoder produce smaller file size with a shorter encoding time (that's surprise me). Ten seconds video encodes about 3 minutes (my hardware is really old for 4k:( ) Software encoding lasts forever, so I not tested it. And last test I used ffmpeg from deb-multimedia and created proxy file for my 4k video sample. Hevc_vaapi decode and h264 vaapi encode with vaapi downscale to 640x360 took around 30 seconds for 10 second video!!! If I use cinelerra's to manually create proxy files (not by menu), just add scale_vaapi filter, then I get following results. The hevc and h262 vaapi encoders uses around 1 min 20 sec (hevc) and 1 minute 45 seconds (h262 main). In case of proxy creation with a menu button, rendering estimates around 42 minutes for 30 seconds video. But I not tested it. So my conclusion that vaapi decoding is extremely useful for playing videos and create proxy files in separate script. @GG how can I use custom script for proxy files creation inside Cinelerra? Or use ffmpeg's scale_vaapi filter if vaapi used. $vainfo libva info: VA-API version 0.39.4 libva info: va_getDriverName() returns -1 libva info: User requested driver 'radeonsi' libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.39 (libva 1.7.3) vainfo: Driver version: Mesa Gallium driver 18.2.8 for Radeon RX 550 Series (POLARIS12, DRM 3.27.0, 4.19.0-0.bpo.4-amd64, LLVM 6.0.0) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc $cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Pentium(R) Dual-Core CPU E5300 @ 2.60GHz stepping : 10 microcode : 0xa0b cpu MHz : 1905.714 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf bogomips : 5200.12 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Pentium(R) Dual-Core CPU E5300 @ 2.60GHz stepping : 10 microcode : 0xa0b cpu MHz : 1833.296 cache size : 2048 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf bogomips : 5200.12 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
В сообщении от Monday 13 May 2019 23:34:47 Спицын Андрей написал(а):
Hi Andrew,
Hi!
Here the quick test results. I used 4k sample video on my PC with RX550 and outdated CPU (ten years-old double-core Pentium)
The variable CIN_HW_DEV affects only on ability to play videos. My test video with vaapi device plays at full speed with around 50% CPU load. The use of 'none' device results in unplayable video (more like slide show). But in both cases I can successfully encode video with hevc_vaapi and h264_vaapi (profile=main) encoders with about 100% CPU load. The hevc encoder produce smaller file size with a shorter encoding time (that's surprise me). Ten seconds video encodes about 3 minutes (my hardware is really old for 4k:( )
Software encoding lasts forever, so I not tested it.
And last test I used ffmpeg from deb-multimedia and created proxy file for my 4k video sample. Hevc_vaapi decode and h264 vaapi encode with vaapi downscale to 640x360 took around 30 seconds for 10 second video!!! If I use cinelerra's to manually create proxy files (not by menu), just add scale_vaapi filter, then I get following results. The hevc and h262 vaapi encoders uses around 1 min 20 sec (hevc) and 1 minute 45 seconds (h262 main). In case of proxy creation with a menu button, rendering estimates around 42 minutes for 30 seconds video. But I not tested it.
So my conclusion that vaapi decoding is extremely useful for playing videos and create proxy files in separate script.
Good to see it worked for you! You probably have slowest CPU here, and fastest/newest GPU. I was looking at bug/feature database, and I think 0000129 - Support for HEVC decode and/or encode hardware acceleration and 0000090 - Allow optional hardware-supported encoding during rendering can be at least updated now, if not closed (some files probably will not play correctly yet? Both h264 and h265 apparently huge and complex and not all features were implemented in hw decoders, especially slightly older ones).
@GG how can I use custom script for proxy files creation inside Cinelerra? Or use ffmpeg's scale_vaapi filter if vaapi used.
$vainfo libva info: VA-API version 0.39.4 libva info: va_getDriverName() returns -1 libva info: User requested driver 'radeonsi' libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.39 (libva 1.7.3) vainfo: Driver version: Mesa Gallium driver 18.2.8 for Radeon RX 550 Series (POLARIS12, DRM 3.27.0, 4.19.0-0.bpo.4-amd64, LLVM 6.0.0) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc
$cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Pentium(R) Dual-Core CPU E5300 @ 2.60GHz stepping : 10 microcode : 0xa0b cpu MHz : 1905.714 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf bogomips : 5200.12 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Pentium(R) Dual-Core CPU E5300 @ 2.60GHz stepping : 10 microcode : 0xa0b cpu MHz : 1833.296 cache size : 2048 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf bogomips : 5200.12 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
@spitsyn.andrey @GG how can I use custom script for proxy files creation inside
Cinelerra? Or use ffmpeg's scale_vaapi filter if vaapi used.
Proxies can not be run easily by remote control or from a shell script. GG does not understand why you would not just use the Settings->Proxy Settings? However, there is nothing special about the actual proxy files -- you can just create the scaled down size with an ffmpeg command line and give it the name which would have been generated by Cinelerra if you had created them that way. For example, test.mp4 would just be test.proxy2-mp4.mpeg if you chose mpeg as the format file type (with mpeg becoming the extension) at 1/2 scale (the 1/2 scale shows as the 2 in "proxy2" of the new file name). VERY IMPORTANT - you must use the ffmpeg binary in Cinelerra's thirdparty directory. Example using mp4:
./ffmpeg -i /root/media/tutorial.mp4 -s 720x540 /root/media/tutorial.proxy2-mp4.mp4 Now when you load the tutorial.mp4 video, and then do Settings->Proxy Settings, the proxy file is already created and will load. ------------------------------------------------------------------------------------------------------------------------------------------- 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 and another line from Cinelerra's thirdparty/ffmpeg directory documentation. We also tried using a .opts file for the import. For example, for test.mp4, we created a test.opts file containing: video_filter=scale_vaapi=1280:720 and that gave us more error messages. Question gg has - can you give us a good working ffmpeg command line using scale_vaapi (again you must use the ffmpeg binary in Cinelerra's thirdparty directory) so we can see it that works for us? Also, why rescale using vaapi instead of using a plugin? Is it faster?
В сообщении от Wednesday 15 May 2019 02:28:57 Phyllis Smith написал(а):
@spitsyn.andrey
@GG how can I use custom script for proxy files creation inside
Cinelerra? Or use ffmpeg's scale_vaapi filter if vaapi used.
Proxies can not be run easily by remote control or from a shell script. GG does not understand why you would not just use the Settings->Proxy Settings? However, there is nothing special about the actual proxy files -- you can just create the scaled down size with an ffmpeg command line and give it the name which would have been generated by Cinelerra if you had created them that way. For example, test.mp4 would just be test.proxy2-mp4.mpeg if you chose mpeg as the format file type (with mpeg becoming the extension) at 1/2 scale (the 1/2 scale shows as the 2 in "proxy2" of the new file name). VERY IMPORTANT - you must use the ffmpeg binary in Cinelerra's thirdparty directory. Example using mp4:
./ffmpeg -i /root/media/tutorial.mp4 -s 720x540 /root/media/tutorial.proxy2-mp4.mp4
Now when you load the tutorial.mp4 video, and then do Settings->Proxy Settings, the proxy file is already created and will load. ------------------------------------------------------------------------------------------------------------------------------------------- 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.
and another line from Cinelerra's thirdparty/ffmpeg directory documentation. We also tried using a .opts file
for the import. For example, for test.mp4, we created a test.opts file containing:
video_filter=scale_vaapi=1280:720
and that gave us more error messages.
Question gg has - can you give us a good working ffmpeg command line using scale_vaapi (again you must use the ffmpeg binary in Cinelerra's thirdparty directory) so we can
see it that works for us? Also, why rescale using vaapi instead of using a plugin? Is it faster?
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
@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 <[email protected]>:
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 [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
@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.
Here the script file: #!/bin/bash filename="$1" fileout="${filename%.*}" proxy="6" # Hardware encode AMD ffmpeg -threads 2 -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i "$1" -c:v h264_vaapi -vf "format=nv12,hwupload,scale_vaapi=iw/'$proxy':ih/'$proxy'" -vcodec h264_vaapi -preset fast -c:a copy -bf 0 -profile:v 66 "$fileout".proxy"$proxy"-mp4.mp4 Note: I used 66 profile for h264 because polaris card not support other profiles.
@spitsyn.andrey: Thanks for the script file. Give me some time to ask GG if there is a way to add this to the shell commands to let you do this inside of Cinelerra. The limitation of *passing the filename is the problem*. When gg added {cinelerra_path}/doc/RenderMux.sh he saved the variable name used from the Render menu, but in this case that is not available obviously. Maybe he can save the last loaded filename and use that. I will see what he thinks. Phyllis Here the script file:
#!/bin/bash
filename="$1" fileout="${filename%.*}" proxy="6" # Hardware encode AMD ffmpeg -threads 2 -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i "$1" -c:v h264_vaapi -vf "format=nv12,hwupload,scale_vaapi=iw/'$proxy':ih/'$proxy'" -vcodec h264_vaapi -preset fast -c:a copy -bf 0 -profile:v 66 "$fileout".proxy"$proxy"-mp4.mp4
@Spitsyn.andrey: concerning your previous message as provided below the asterisks (***). A change to the Shell Commands has been checked into GIT that I believe should get you what you can use when you use the "Add" option after going to: Settings->Preferences->Interface->Shell Commands. I have not documented how to use it yet but I am pretty sure you will understand how to use it as I barely do. Be sure when doing the Add to check the box "run /path/script.sh + argv" to run that script. I believe this is all you have to do to get this working: 1) put your script as you described earlier below anywhere on your system that will not be deleted 2) set up you Shell Command as described in the CinelerraGG_manual.pdf basically do an Add, type in the line /{your directory path}/your_script_file.sh and check the "run" box 3) click all OKs to get back to Cinelerra 4) NOW to execute your script from inside Cinelerra, assuming you have loaded your video files/assets, highlight the 1 file in the Resources Window that you want to proxy using your script, then use the Shell Cmds icon to find the Add that you did and click on it. I would suggest you look at the output on the window from where you started up Cinelerra to make sure it is working or your script could include an output log file. You can also use $1, $2, ... more args in your script and then highlight multiple files. Let me know if this works for you or what the problem is if it does not. Thank you as this was a good addition for us. gg/Phyllis ************************************************************************************************* On Wed, May 15, 2019 at 1:22 AM Спицын Андрей <[email protected]> wrote:
@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.
Here the script file:
#!/bin/bash
filename="$1" fileout="${filename%.*}" proxy="6" # Hardware encode AMD ffmpeg -threads 2 -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i "$1" -c:v h264_vaapi -vf "format=nv12,hwupload,scale_vaapi=iw/'$proxy':ih/'$proxy'" -vcodec h264_vaapi -preset fast -c:a copy -bf 0 -profile:v 66 "$fileout".proxy"$proxy"-mp4.mp4
Thank you very much. This would be be very helpful. Can you provide me debian 9 amd64 package for testing please. пт, 31 мая 2019 г., 5:28 Phyllis Smith <[email protected]>:
@Spitsyn.andrey: concerning your previous message as provided below the asterisks (***). A change to the Shell Commands has been checked into GIT that I believe should get you what you can use when you use the "Add" option after going to: Settings->Preferences->Interface->Shell Commands. I have not documented how to use it yet but I am pretty sure you will understand how to use it as I barely do. Be sure when doing the Add to check the box "run /path/script.sh + argv" to run that script. I believe this is all you have to do to get this working:
1) put your script as you described earlier below anywhere on your system that will not be deleted 2) set up you Shell Command as described in the CinelerraGG_manual.pdf basically do an Add, type in the line /{your directory path}/your_script_file.sh and check the "run" box 3) click all OKs to get back to Cinelerra 4) NOW to execute your script from inside Cinelerra, assuming you have loaded your video files/assets, highlight the 1 file in the Resources Window that you want to proxy using your script, then use the Shell Cmds icon to find the Add that you did and click on it. I would suggest you look at the output on the window from where you started up Cinelerra to make sure it is working or your script could include an output log file.
You can also use $1, $2, ... more args in your script and then highlight multiple files. Let me know if this works for you or what the problem is if it does not. Thank you as this was a good addition for us. gg/Phyllis
*************************************************************************************************
On Wed, May 15, 2019 at 1:22 AM Спицын Андрей <[email protected]> wrote:
@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.
Here the script file:
#!/bin/bash
filename="$1" fileout="${filename%.*}" proxy="6" # Hardware encode AMD ffmpeg -threads 2 -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i "$1" -c:v h264_vaapi -vf "format=nv12,hwupload,scale_vaapi=iw/'$proxy':ih/'$proxy'" -vcodec h264_vaapi -preset fast -c:a copy -bf 0 -profile:v 66 "$fileout".proxy"$proxy"-mp4.mp4
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
The new builds are now available with this mod in. We do not actually test them all but did Leap 15.1. https://www.cinelerra-gg.org/download/pkgs/debian9/cin_5.1.debian9-20190531_... On Fri, May 31, 2019 at 2:43 PM Андрей Спицын <[email protected]> wrote:
Thank you very much. This would be be very helpful. Can you provide me debian 9 amd64 package for testing please.
пт, 31 мая 2019 г., 5:28 Phyllis Smith <[email protected]>:
@Spitsyn.andrey: concerning your previous message as provided below the asterisks (***). A change to the Shell Commands has been checked into GIT that I believe should get you what you can use when you use the "Add" option after going to: Settings->Preferences->Interface->Shell Commands. I have not documented how to use it yet but I am pretty sure you will understand how to use it as I barely do. Be sure when doing the Add to check the box "run /path/script.sh + argv" to run that script. I believe this is all you have to do to get this working:
1) put your script as you described earlier below anywhere on your system that will not be deleted 2) set up you Shell Command as described in the CinelerraGG_manual.pdf basically do an Add, type in the line /{your directory path}/your_script_file.sh and check the "run" box 3) click all OKs to get back to Cinelerra 4) NOW to execute your script from inside Cinelerra, assuming you have loaded your video files/assets, highlight the 1 file in the Resources Window that you want to proxy using your script, then use the Shell Cmds icon to find the Add that you did and click on it. I would suggest you look at the output on the window from where you started up Cinelerra to make sure it is working or your script could include an output log file.
You can also use $1, $2, ... more args in your script and then highlight multiple files. Let me know if this works for you or what the problem is if it does not. Thank you as this was a good addition for us. gg/Phyllis
*************************************************************************************************
On Wed, May 15, 2019 at 1:22 AM Спицын Андрей <[email protected]> wrote:
@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.
Here the script file:
#!/bin/bash
filename="$1" fileout="${filename%.*}" proxy="6" # Hardware encode AMD ffmpeg -threads 2 -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i "$1" -c:v h264_vaapi -vf "format=nv12,hwupload,scale_vaapi=iw/'$proxy':ih/'$proxy'" -vcodec h264_vaapi -preset fast -c:a copy -bf 0 -profile:v 66 "$fileout".proxy"$proxy"-mp4.mp4
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Saturday 01 June 2019 01:04:02 Phyllis Smith написал(а):
The new builds are now available with this mod in. We do not actually test them all but did Leap 15.1.
Ah, this was fast. Just in case I still uploaded my Debain 9 (x86-64) single-user build to https://cloud.mail.ru/public/2SM5/2x3DPD4sU look for xz file. sha256sum was updated. I think I'll just keep this VM around, but if regular builds now include Debian9/10 - there is no need for duplicating official efforts?
https://www.cinelerra-gg.org/download/pkgs/debian9/cin_5.1.debian9-20190531_...
On Fri, May 31, 2019 at 2:43 PM Андрей Спицын <[email protected]> wrote:
Thank you very much. This would be be very helpful. Can you provide me debian 9 amd64 package for testing please.
пт, 31 мая 2019 г., 5:28 Phyllis Smith <[email protected]>:
@Spitsyn.andrey: concerning your previous message as provided below the asterisks (***). A change to the Shell Commands has been checked into GIT that I believe should get you what you can use when you use the "Add" option after going to: Settings->Preferences->Interface->Shell Commands. I have not documented how to use it yet but I am pretty sure you will understand how to use it as I barely do. Be sure when doing the Add to check the box "run /path/script.sh + argv" to run that script. I believe this is all you have to do to get this working:
1) put your script as you described earlier below anywhere on your system that will not be deleted 2) set up you Shell Command as described in the CinelerraGG_manual.pdf basically do an Add, type in the line /{your directory path}/your_script_file.sh and check the "run" box 3) click all OKs to get back to Cinelerra 4) NOW to execute your script from inside Cinelerra, assuming you have loaded your video files/assets, highlight the 1 file in the Resources Window that you want to proxy using your script, then use the Shell Cmds icon to find the Add that you did and click on it. I would suggest you look at the output on the window from where you started up Cinelerra to make sure it is working or your script could include an output log file.
You can also use $1, $2, ... more args in your script and then highlight multiple files. Let me know if this works for you or what the problem is if it does not. Thank you as this was a good addition for us. gg/Phyllis
*************************************************************************************************
On Wed, May 15, 2019 at 1:22 AM Спицын Андрей <[email protected]> wrote:
@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.
Here the script file:
#!/bin/bash
filename="$1" fileout="${filename%.*}" proxy="6" # Hardware encode AMD ffmpeg -threads 2 -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -i "$1" -c:v h264_vaapi -vf "format=nv12,hwupload,scale_vaapi=iw/'$proxy':ih/'$proxy'" -vcodec h264_vaapi -preset fast -c:a copy -bf 0 -profile:v 66 "$fileout".proxy"$proxy"-mp4.mp4
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (4)
-
Andrew Randrianasulu -
Phyllis Smith -
Андрей Спицын -
Спицын Андрей