3 ms·
This bit made me gasp a bit: "[...] all it needs [...]" Off the top of my head: >video output Meaning: RW access to /dev/dri/cardX on desktop. In an embedded
by bostik 13y ago
This bit made me gasp a bit: "[...] all it needs [...]"
Off the top of my head:
>video output
Meaning: RW access to /dev/dri/cardX on desktop. In an embedded system, replace that with /dev/fbX. In most cases, we're rendering to GL buffers. Do you trust the GL drivers to be completely bug free? (Hint: from some embedded drivers I've dealt with I find it remarkable they work at all.)
>doesn't need to [...] open network connections
How about RTMP streaming? Or DLNA discovery and playback?
Some of the cases may be protected with sandboxing, but I have serious doubts about getting anything near complete coverage.
- chubot 13y agoThe network stuff should be replaceable with a file descriptor and a dead simple app-specific protocol. Just like Chrome has a little protocol for communicating between the UI and renderer processes. I think you could also provide less than full access to the graphics driver. You could have a file descriptor or shared memory protocol, with the sandboxed process outputting video frames, and the parent process actually communicating with the driver. In addition to being more secure, it's also better software architecture. VLC/ffmpeg are already way more modular than say the Microsoft equivalents.