From: "Steve Oakley" <AE-List@media-motion.tv>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Subject: Re: [AE] Lossless movie format
In-Reply-To: <list-5498736@media-motion.tv>
Date: Tue, 10 Jun 2014 18:34:35 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <55573F16-F36C-426C-9ADC-9E0D16F86F65@practicalillusions.com>
References: <list-5498736@media-motion.tv>
To: After Effects Mail List <AE-List@media-motion.tv>


On Jun 10, 2014, at 4:50 PM, Brendan Bolles <AE-List@media-motion.tv> =
wrote:

> On Jun 9, 2014, at 11:03 AM, Steve Oakley wrote:
>=20
>> 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.
>=20
> 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.

ok, when I wrote that I thought about what if Apple where to add ARM =
processors to OS X for laptops ? or that they take ARM CPU's to compete =
with x86 on the desktop level ?

so you embed both. also lets define this. I realize that if you want to =
do some operations like GUI interaction its obviously completely =
different between platforms but.... lets take the core compression code =
and embed that. Its API is to MOX's main lib, not the entire OS. it only =
needs to talk to MOX.  this is a fall back and option.

I'm not worried about MOX opening on andriod..... Linux maybe if =
material had to go to smoke / flame.=20

>=20
> 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.

thats fine. if file.codec.ver < installed.codec.ver then decode with =
installed codec


> 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.

honestly I'd run with single file MXF if there was a universal codec ( =
you know the laundry list of must have's ). I care far less about the =
container. IN fact enough apps can't deal with MXF that its probably =
more a limitation than anything else.

> 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."


I agree. careful, controlled growth. Not a free for all of components =
and codecs being added would aid long term stability.

S=