What is described is already reality - I see it every day. I work for a company writing its own video codecs, who have a format that downloads a 70KB jar file

What is described is already reality - I see it every day. I work for a company writing its own video codecs, who have a format that downloads a 70KB jar file before streaming the video. It's a Java applet (and still supports Java 1.1 - we've been doing this for a number of years now) and largely allows the model that Stanislav wishes. Is it ideal? Probably not. We can't do fullscreen or hardware-optimised playback. We have to implement our own controls that are out of place of the L&F of the OS and browser. We need people to install the Java VM. On Java versions older than JDK6u18 we still only get to use 64MB of memory (on a 2GB machine? Hah!). Not always going to work on your latest smartphone. On the flip side, I also see a lot of video container formats where people try to standardise something as generic as possible. Particularly OMFI (Bento), Quicktime, AAF. The simplest AAF File which simple refers to a piece of video content elsewhere is 250KB, because it has to define a complete vocabulary of items that it might deal with in the file, and jumps from pointer to pointer to actually get to the data. It's pretty much the closest we have to Stanislav's 1961 Air Force quote example, with everything short of actually including a decoder specification for the audio and video content. It's a minefield to work with. It's too flexible for its own good, and reading or writing it is anything but a trivial task (cue large libraries, larger than video decoders, to do that. Anything but ideal). So, one side involves a virtual machine to standardise hardware, and the other needs large libraries to parse and emit even the simplest of files. I've seen this world, and I think I'd rather have well-implemented standard decoders working on simpler wrappers instead.