<br><br>On Tuesday, January 18, 2022, Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com">randrianasulu@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, I compiled new Cingg git (gcc 5.5.0,  ~ Slackware 14.2,  32 bit (!)) <div><br></div><div>file 1920x1080 24 fps h264 mkv from youtube</div><div><br></div><div>no plugins/effects/transitions</div><div><br></div><div>default project format - rgba-8bit<br><div><br></div><div>and va-api works for me on both decoding (most visible cpu usage reduction if i set output to x11-direct - 60% g> 30%), on opengl output it really clise to same 60-70% cpu utilization (one core, dynamic freq.) and encoding</div><div><br></div><div>you need to restart Cin after changing hw accel method</div><div><br></div><div>But biggest thing was va-api h264 encoding  - 130% cpu and 18 fps vs nearly 400% cpu and 2 fps (while file size more like 5 mb for software vs 13 mb for vaapi). And memory usage with sw encoding much higher = 800/900 mb vs 300 mb in va-api case. I nearly deadlocked this 4gb ram laptop while trying ram-only (tmpfs) build and encoding tests... zram + zswap  helped surely... </div></div></blockquote><div><br></div><div>2 fps was due to x264 not picking up old nasm - it seems 2.13+ needed for libjpeg-turbo too (according to its own building instruction) </div><div><br></div><div>With normally-compiled x264 I got 9.66 fps - much better! </div><div><br></div><div>So, this is another hazard (speed-wise) - old nasm may work for some components and do not work for others (with significant encoding speed loss) </div>