Declan_Vee wrote:Hey all,
Last night someone from my anime club brought in a video thing called "Red vs Blue"... or was it "Blue vs Red" I can't remember, namely because I was getting a drink when we tried to play it. It refused to cooperate, some new DivX codec... I dunno DivX6 (irrelevent).
An interesting idea came out of this though. Videos with the decoder embedded in the file. Considering that codecs aren't all that big (a few hundred Kb or so) no such a bad idea. A new media player that has the ability to read and use these decoders may have to be developed. But otherwise it's not too far fetched... radical, yes. Impossible, probably not.
This is probably a topic better suited for doom9, but I'd like to hear what anyone here thinks about it.
Insecure and a cross-compatibility headache.
I'll expand on both of those.
First off...it's ironic. Embedding code and data into the same package is the concept that drives modern software development. It's the concept that brought us funky languages like LISP and PROLOG.
But it's the same concept that makes macro viruses and malvolent ActiveX controls work
You'd have to have a very trusted code-signing infrastructure in place BEFORE you do anything like this. TCPA may be able to help out with that in some respect; I haven't researched enough on it to give a definitive "yes" or "no".
Before then, however, I wouldn't trust such a file. Ever. Even then, I'd be EXTREMELY cautious, because what you propose is like a dark, warm room to microorganisms: extremely receptive to propagation of nasty stuff.
There's also the cross-platform issue. Even a Sorenson v3 Quicktime-encoded file will play fine on my XP laptop, on my Gentoo editing system, and a PowerMac G4 tower. In order to retain cross-compatibility, a file like what you propose has two options:
(1) Include versions for ALL OSes, on ALL players.
(2) Make the code OS-independent. This is possible; Metro Link did it with their object loader, which is used in e.g. XFree86. But that requires the object loader to be present on the user's system.
Neither option is desirable. Option (1) is feasible, but only slightly so -- it'd mean that you'd have to include a fair amount of interfaces. Option (2) would be nice if we could all play along and use the same executable format, but THAT won't ever happen. We have at least three major executable formats in use at the moment across the span of consumer OSes: PE (Windows), ELF (many Unices), and Mach-O (Mac OS X executables). Good luck.
You could develop a media player that incorporated a platform-independent module loader, but you'd still have the same cross-platform problem (granted, to a lesser extent).
Another problem. Who dictates when the codec interfaces to the player break? (It's going to happen; nothing is ever right the first time.) When that happens, do all the old video files suddenly become unplayable? Do you incorporate some sort of interface version tag of sorts to prevent that from occurring? How do you keep that tag constantly accessible through many changes that could break binary compatibility in weird ways?
This is a block of text that can be added to posts you make. There is a 512 character limit.