Well, I only tested 1) 1) add fast lowres=3 skiploopfilter=all to your decode.opts file lowres really only work for dv/mpe2/mjpeg. 3 is really aggressive, try 1 or 2 if it works at all. 2) Set scaling method to simplest, nearest. Obviously only work if you do not do scaling, or plan to redo it anyway at higher quality. 3) Look if replacing -Ofast with " -mach=yourcpu, -mtune=yourcpu" works better (grep Makefiles to see where it set) 4) Add same march/mtune cflags to individual plugins Makefiles and see if it really speed ups them. 5) Hard - look into openmp parallel/simd directives and see if they apply to any for loops in slow plugins. 6) As I said - proxies ... It seems that in worst case scenario (g=250 frames, fps=25) for fast (less than 1 second) seeking to any point in stream you need nearly 10x more power that was needed for mere playback! It goes better for smaller g and bigger fps, but still. H265/4/2 was not designed as editing format, and you only can brute force your way so far .... 7) Look if mesa3d tracker has any issue with vaapi decoding crashing cingg. I added one case but it probably was just incomplete implementation in nouveau. I avoided some crashes by disabling those filmstrip icons as fast as I can after loading media. ymmv. I suspect way cingg drives ffmpeg and ffmpeg in turn drives vaapi driver is quite different from usual player/streaming case, but you probably need some thread debugging flags added everywhere and knowledge about how to interpret their output.