Updated and checked into GIT, libvpx from 1.8.2 to 1.11.0. Compiled and 1 test on Fedora 32, Debian 9.1-32bit, and Ubuntu 16.04 and the reason was because the notes said Nasm 2.15 recommended. But Debian and Ubuntu both were at 2.13 and compiled OK and I rendered to VP9. Andrea, if you use VP9 a lot, could you do a couple of test on your Arch system? Andrew, I did update the patch1 also so I think I did it correctly but if not, just let me know. ...Phyllis
On Friday, February 18, 2022, Phyllis Smith via Cin < [email protected]> wrote:
Updated and checked into GIT, libvpx from 1.8.2 to 1.11.0. Compiled and 1 test on Fedora 32, Debian 9.1-32bit, and Ubuntu 16.04 and the reason was because the notes said Nasm 2.15 recommended. But Debian and Ubuntu both were at 2.13 and compiled OK and I rendered to VP9.
was speed the same as with old nasm, or slower?
Andrea, if you use VP9 a lot, could you do a couple of test on your Arch system? Andrew, I did update the patch1 also so I think I did it correctly but if not, just let me know. ...Phyllis
/me looks for something to delete for compilation... (android apps tend to take more space as they updated.. so, same set of apps eats into free space with time...)
My test. Compiling from git: OK. Create new project 1080p/25fps/RGBS-Float: OK. Checked "Play every frame" and Driver=X11-OpenGL. With hardware acceleration on "none": Playback forward: OK Playback reverse: ~OK Manual scrub: ~OK Rendering (37s): 18 fps (single thread!) With hardware acceleration on "vaapi": Playback forward: OK Playback reverse: BAD Manual scrub: BAD Rendering (37s): 18 fps (single thread!)
On Friday, February 18, 2022, Andrea paz <[email protected]> wrote:
My test. Compiling from git: OK. Create new project 1080p/25fps/RGBS-Float: OK. Checked "Play every frame" and Driver=X11-OpenGL.
i think right now x11 (all versions) output must convert from rgba-float to rgba8, and vaapi also outputs at best 10-12 bit integer format, so conversion to project's format also necessary...
With hardware acceleration on "none": Playback forward: OK Playback reverse: ~OK Manual scrub: ~OK Rendering (37s): 18 fps (single thread!)
did you tried various vp9 presets?
With hardware acceleration on "vaapi": Playback forward: OK Playback reverse: BAD Manual scrub: BAD Rendering (37s): 18 fps (single thread!)
In X11, using YUVA8 I find the same playback efficiency of RGBA-Float. With RGBA8 the playback is similar, but using vaapi it improves a bit in reverse. The problematic vp9 video is as follows: https://www.base-n.de/webm/VP9%20Sample.html Other vp9 videos work much better. Rendering Starting from RGBA8: 1080p/422p/25fps : 27 fps 1440p/422p/25fps : 24 fps Starting from YUVA8: 1080p/422p/25fps : 21 fps
On Friday, February 18, 2022, Andrea paz <[email protected]> wrote:
In X11, using YUVA8 I find the same playback efficiency of RGBA-Float. With RGBA8 the playback is similar, but using vaapi it improves a bit in reverse.
The problematic vp9 video is as follows: https://www.base-n.de/webm/VP9%20Sample.html Other vp9 videos work much better.
strange, it does not look particulary big (nor in duration nor in dimensions)...
Rendering
Starting from RGBA8: 1080p/422p/25fps : 27 fps 1440p/422p/25fps : 24 fps
Starting from YUVA8: 1080p/422p/25fps : 21 fps
so, close to realtime on your hardware..... https://www.linuxfromscratch.org/blfs/view/svn/multimedia/libvpx.html according to this page nasm OR yasm can be used (for compiling x86 assembly parts), so may be older distros still get full-speed encoder...
participants (3)
-
Andrea paz -
Andrew Randrianasulu -
Phyllis Smith