bjano

Nothing is uploaded, everything runs locally.

.avi file just shows a spinner in place of the preview, never finishes loading

.mkv files are not enabled in the file picker, if I select one anyway it loads, but the export hangs

hevc .mp4 loads, but the exported video is all black

The site claims "versatile codec support" but I couldn't get it work with anything except the most vanilla h264 files.

(though as I am working on a similar product I am aware that handling all the codecs is quite a bit more painful than it first seems)

You don't need to keep the video files in memory, it's enough to have the javascript File object and then you can read the packets you need on the fly. This way the app's memory usage should be okay.

This is what I did in my similar project (vidmix.app) and seems to be what OP's project is doing, except that they also copy the file to indexedDB to keep it around after the browser tab is closed.

It seems to me that the demonstration is calculated in sRGB space, so with non-linear brightness values and I suspect that most of the unnaturalness of the smear is due to that. To simulate the physics this would need to be done with linear brightness values and only at the end converted to sRGB.

(unless some non-linear effects in human visual perception cancel all that out, but it should at least be mentioned if so)

I've been having the same issue with an app. Random rejections with a single line copy-pasted from the (genuine) feature list in the app description. In this case the lines just start with a regular dash ("-").

This together with the sometimes 10+ day review times makes it impossible to maintain an app on the Play Store now.

I use a WebAssembly build of FFmpeg to extract the streams and packets from the video files and as a fallback for some codecs. But most of the decoding/encoding is done with WebCodecs which in most cases has access to hardware acceleration so can be much faster than ffmpeg.

Yes, the shortcomings of the html video tag are quite unfortunate. Just some very small improvements would make it a lot more useful. One other issue I found at the time I was looking at it (not sure if it's still the case) was that stepping one frame forward wasn't any faster than seeking from a random location. Seemed like the video was decoded from the last keyframe every time, making it inefficient to iterate through the frames.