I'm working on porting ffplay, targeting HEVC but also all the other decoders if possible. I've had nothing but trouble from emscripten and have had to start from the beginning, just using ffplay as reference and very slowly building the application up.
Emsriptens proxy_to_thread option doesn't transfer the document context correctly, so calls from SDL to change canvas size, mouse scroll events, etc, all error. I just had to comment those lines out.
But then the program would infinitely lock because a mutex would not return when a pthread was created. It would just spin on mutex.wait, and there were no errors in the thread creation as I tracked it line by line.
Then debugging randomly wouldn't compile anymore.
There's a whole blog I'll write on it but the summary is that emscripten is cool, but the quality of it's features isn't ready to simply cross compile without the underlying code supporting it.
I would be interested to sponsor development of a project that could reliably play large video files with different formats in the browser. I'd use it adapt our Chrome extension ('Language Learning with Netflix') into a website/SPA that could load in local video files, so you could study with movies from your hard drive. Contact email is in my profile. :-)
WebRTC doesn't add anything for his usecase of playing local files. WebRTC is an API to let the browser stream data (including video/audio) over the network. If the browser can play the given video by supporting that codec then you can play it using a HTML5 <video> element directly from local disk. No network communication needed.
Ah yes, didn't think about the use case of unsupported codecs. Though at that point I would argue it would be easier to convert the file with ffmpeg, etc, then to use a custom decoder in the browser.
Emsriptens proxy_to_thread option doesn't transfer the document context correctly, so calls from SDL to change canvas size, mouse scroll events, etc, all error. I just had to comment those lines out.
But then the program would infinitely lock because a mutex would not return when a pthread was created. It would just spin on mutex.wait, and there were no errors in the thread creation as I tracked it line by line.
Then debugging randomly wouldn't compile anymore.
There's a whole blog I'll write on it but the summary is that emscripten is cool, but the quality of it's features isn't ready to simply cross compile without the underlying code supporting it.