From: "Brendan Bolles" <AE-List@media-motion.tv>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1085)
Subject: Re: [AE] Lossless movie format
In-Reply-To: <list-5497816@media-motion.tv>
Date: Tue, 10 Jun 2014 14:50:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <1E1932A1-9FE8-453B-8D50-D28AA152BA4F@fnordware.com>
References: <list-5497816@media-motion.tv>
To: "After Effects Mail List" <AE-List@media-motion.tv>

On Jun 9, 2014, at 11:03 AM, Steve Oakley wrote:

> in fact here is an idea - Put the codec IN the media file as an =
option. this would guarantee codec install problems would never be a =
problem. its a minor bit of file bloat but if the actual codec code is a =
couple kb, even 50kb thats really nothing. this would solve all sorts of =
problems around users not having the latest codec, or correct one =
assuming down the road MOX opens up and extends to new codecs.


I'm sorry to be a wet blanket, but I don't think this is do-able.

Codecs are software, and software is built for a platform and processor =
architecture.  So the Mac codec you embed would not work on Windows.  Or =
if you embed both Mac and Windows, the file still won't open on Android, =
or on some other future platform that hasn't yet been created.  This is =
exactly the type of situation I'm hoping to avoid.

Also, software codecs can be improved over time and their bugs can be =
fixed, but if you embed a codec into the file, it will be set.


Some people have asked for extensibility, but extensibility is the enemy =
of compatibility.  If you let people add codecs via plug-ins or write =
their own codecs into MOX files, you're right back where we started with =
QuickTime and generalized MXF.  Which is fine, there's totally a place =
for that.  We've already got that.  One of the main ideas in MOX is to =
lock some things down so that you can be totally that any MOX file you =
write can be read by any program that reads MOX.

This doesn't mean more codecs couldn't be added to the list in the =
future.  OpenEXR did this, later adding the B44 and B44A compression =
options.  Early adopters who wrote files with B44 knew that many =
existing programs would not be able to read their files until they =
updated their libraries, but eventually every program would be able to =
read those B44 files because B44 was part of the OpenEXR library, not =
some plug-in.

I would love if someday a vendor were to say, "I want to write MOX =
files, but with this awesome codec we've created."  My response would =
be, "No problem, release the source code and we'll include it in the =
standard."


Brendan