Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1085)
Subject: Re: [AE] lossless codec in a container roundup
From: Brendan Bolles <brendan@fnordware.com>
In-Reply-To: <list-5149382@media-motion.tv>
Date: Mon, 22 Jul 2013 09:02:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <8045C29D-1D7E-41BF-B4CB-1F9C87FF6238@fnordware.com>
References: <list-5149382@media-motion.tv>
To: "After Effects Mail List" <AE-List@media-motion.tv>

On Jul 21, 2013, at 12:42 PM, Steve Oakley wrote:

> what would it take to write Dirac into single file MXF or QT as =
containers ? seems to me that using established well known containers =
would mean only needing to add the codec into the right place in your =
system and then you could easily r/w the files and exchange them. no =
doubt if Ogg container only had to live on my machine it would be fine, =
but exchange becomes more of an issue.  I'd rather see a standard =
documented container with a common codec than yet another new container =
format.


This is a good conversation to have.

Let me start right off by saying I don't see how having a familiar =
container with a missing codec is better than having an unfamiliar =
container with an unknown codec.  Either way you can't read it.  Writing =
Dirac codecs for QuickTime or MXF may still be a worthy project, but =
I'll tell you why I'm not leaning that way.

If someone hands you a random MXF, you can't have absolute confidence =
you can read it.  It might contain MPEG-2, DNxHD, JPEG 2000, or who =
knows.  And now we'd propose to add several more codecs to further muddy =
the situation?  This is the same deal for QuickTime with its variety of =
third-party codecs or even TIFF with the multitude of things people may =
pack into it.

I much prefer the situation with OpenEXR, where an importer built with =
the latest library should be able to read any EXR ever made.  This is =
made possible by having a well-written reference library that includes =
code for all the codecs, delivered with the BSD license.

The reason I'm leaning toward the Ogg container is precisely because it =
is currently unfamiliar to most, including professional and casual =
users.  It still has a mostly clean slate, ready to be built upon.  The =
Ogg philosophy is also very closely aligned with open source, with all =
the codecs you're currently likely to find in an Ogg container (Theora =
video, Vorbis or FLAC audio) fully open.  We would include these codecs =
and add to the list, able to read any current .ogv file.

Another option is to take an established container and re-brand it.  For =
example WebM is a Matroska container that is limited to VP8 video and =
Vorbis audio.  This might be a good idea if we found there was some =
limitation in the Ogg container or some benefit from using another =
container.


Brendan