what are your system specs? at a low effort you should be getting a lot more FPS, what cli command are you using? but I guess it would be best for you to export to /tmp given enough ram and then go from there
EDIT: for context, when encoding libjxl I would do -distance 0 -effort 2 for lossless output
going from YUV->RGB wont incur any meaningful loss, going from RGB -> YUV on the other hand can, but it's rare that it will actually happen so long as you arent messing up your bitdepth too much
A) Export using a lower effort, with libjxl effort 2 or something will be fine.
B) Export to a faster image format like QOI or TIFF or PPM/PNM etc.
PNG, JXL, WEBP, all have fairly high encode times by default with ffmpeg. lower the effort or use a faster format
If you think that it really could be write speed limitations, encode to a ramdisk first then transfer if you have the spare ram, but using a different and faster format will probably help as PNG is still very slow to encode. (writing to /tmp is fine for this)
This has been a thing for a long time
Boring hit piece that way overblows some issues on the topic.
this is quite frankly, a really dumb picture that is wrong on many accounts
sounds like a lot of work when you could just install arch or nobara and be done with it
literally, all Chrome OS / chromium OS needs to do for me to actually embrace it. is native out of box flatpack support
one issue I might see them having with flatpack, is the permissions right now are handled kind of stupidly IMO. but if those get solved I think flatpack would be a great addition to chromium os ecosystem
all chromeOS needs to be immensely more useful is flatpak support, if chrome OS supported flatpaks directly, it could very well be my goto (well not chromeOS directly, probably thoriumOS) for older linux PCs for general populace
Have you considered using av1an? it supports vaporsynth which has a large amount of upscale and frame interpolation tools, AI or not. If your upscaler supports vapoursynth, it could be a lot better option.