Videos don't load properly #202
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Splitting this from #201 since this issue is affecting MP4 and webm videos on non-Safari browsers.
Videos can sometimes appear blank with a 0 second duration like the following:
They will still play once clicked, but this is pretty annoying.
I'm suspecting this has to do with needing to set CORS headers for those to load properly.
The problem here is that FoundKey serves media files directly from the app, which precludes seeking. With improperly muxed files, this can prevent playback entirely.
One solution to this is letting a reverse proxy like nginx handle this. However:
/filesis created readable only to the FoundKey user, which is awkward when the nginx process runs as a different userX-Accel-Redirectthis would also prevent setting the correct MIME type or implementing any sort of access controlFWIW, this doesn't happen in Akkoma. Both are using the default reverse proxy settings that Caddy uses in my case.
I guess Akkoma is handling HTTP range requests then?
I'd have to take a closer look when I have time.
I don't think that is deliberate on our side. We just copy whatever file
@koa/multergives us. I did not see any configuration options formulter(which@koa/multeruses) to set file permissions. It just seems to use node's built infs.createWriteStreamwhich says the default file mode is0o666.Maybe there is something else going on, like umask?
The access control consists only of knowing the UUID. Foundkey does not implement incoming signed fetch. Even if it did, more access controls would break media for users that are on instances which cannot/do not want to enable caching.
Can’t be umask at least. I’ve checked
/proc/<pid>/statuson all FoundKey processes and they all showUmask: 0022. Can’t be directory ACLs either.I don't even think it has to do with anything with filesystem permissions since this tends to happen with remote media (and I have caching turned off).
Yeah I meant fs permissions are only an issue if you want to serve files from a process running as a different user, like nginx (assuming FoundKey gets its own user). Having nginx serve those files fixes video playback. But I guess that still leaves uncached files.
I’m 99% sure the issue is FoundKey not supporting HTTP range requests on media files. FFmpeg also complains about this on ISOBMFF files that were not muxed with the moov atom at the start (“-movflags +faststart” option with FFmpeg’s muxer, or using qt-faststart), and mpv refuses to play them. With browsers it’s a hit and miss; sometimes it works when the whole file is already cached.
Yeah the issue is that Koa does not support range requests by default.
There's https://github.com/koajs/koa-range but it's unmaintained.
Since I don't understand what the hell was/is going on that makes multer set different permissions sometimes, we now explicitly set the file permissions to
-rw-r--r--after copying the file from/tmpfor internal storage.