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