I used to develop something like this (5-6 years ago). By far the best (most stable and performant) solution was the following:
- Linux OS (ease of management, installation, introspectability).
- Debian (somewhat stripped down), with custom packages.
- Puppet for node management.
- runit as a process manager.
- Chromium to display videos/presentations.
- (Custom) NPAPI based plugin (shim) that would load mplayer-vaapi (nowadays it would be mpv I guess) to display videos.
It worked because one could get the X window ID of the <video> element via NPAPI, which was then passed to mplayer so it could initialize/render within the sub-window.
One of the main benefits was that this avoided lots of resource leaks. The plugin pre-loaded mplayer processes and would shut them down after the video finished playing. Transitions were near to seamless (though required some HTML hacks to avoid white flashing).
On our Sandy Bridge machines (small form factor, fanless), we could display 16 1080p videos side-by-side for days and the machine would stay cool. I was so excited when I demonstrated this. The previous interation of this software used the regular <video> (software) implementation and could barely manage a single video without overheating.
Of course, NPAPI was deprecated a long time ago and removed from Chromium more than a year ago I think. The "replacement" (at the time) Pepper API AFAIK didn't allow access to the X window which is needed by mplayer. It was also not compatible between browsers. The plugin I made also worked on Firefox.
Nowadays access to the necessary resources is so walled off that you'd really need hardware acceleration to be native to the browser. There'd be hard-to-avoid resource leaks, so I'd schedule browser restarts at night-time. I've been out of the loop for a while so maybe there's better stuff. I remember monitoring the Chromium repository to see if they would implement hardware acceleration. I recall they had a branch where this was "working" on ChromeOS and supposedly you could force-enable this for general Linux. I tried building this once, but my machine at the time could barely handle building it (took many hours). Once the binary was built, it would crash at startup. I decided it was too much effort to replace a solution that was working perfectly.
One of the main benefits was that this avoided lots of resource leaks. The plugin pre-loaded mplayer processes and would shut them down after the video finished playing. Transitions were near to seamless (though required some HTML hacks to avoid white flashing).
On our Sandy Bridge machines (small form factor, fanless), we could display 16 1080p videos side-by-side for days and the machine would stay cool. I was so excited when I demonstrated this. The previous interation of this software used the regular <video> (software) implementation and could barely manage a single video without overheating.
Of course, NPAPI was deprecated a long time ago and removed from Chromium more than a year ago I think. The "replacement" (at the time) Pepper API AFAIK didn't allow access to the X window which is needed by mplayer. It was also not compatible between browsers. The plugin I made also worked on Firefox.
Nowadays access to the necessary resources is so walled off that you'd really need hardware acceleration to be native to the browser. There'd be hard-to-avoid resource leaks, so I'd schedule browser restarts at night-time. I've been out of the loop for a while so maybe there's better stuff. I remember monitoring the Chromium repository to see if they would implement hardware acceleration. I recall they had a branch where this was "working" on ChromeOS and supposedly you could force-enable this for general Linux. I tried building this once, but my machine at the time could barely handle building it (took many hours). Once the binary was built, it would crash at startup. I decided it was too much effort to replace a solution that was working perfectly.