Jump to content
Sign in to follow this  
foughtthelaw

Mox: Open Source / Patent free file format

Recommended Posts

Interesting project. Nice to see some familiar backers, so I guess it's getting good support. A certain Mr Babb has got his cheque book out...

 

One question for the technical types here - revealing my ignorance: I was under the impression that movie formats are the small picture, the bigger problem is efficient lossy and lossless compression. Whatever wrapper you put on your file, you'll still need a codec, and that's where the licensing factor creeps back in. And compressing footage efficiently is pretty intense from a mathematical point of view, it's not just counting ones and zeros, so knocking up your own codec is a tall task. They have to compress in real-time during recording, perhaps with HW support, and decompress quickly enough to be able to scrub a timeline without massive lag.

 

Are they dealing with this part of the problem, or is it all about the wrapper, and replacing Quicktime?

Share this post


Link to post
Share on other sites

I believe it's using existing open-source codecs such as Dirac, PNG and FLAC inside the new wrapper. AFAIK the new super-duper codecs such as H265 are the future in terms of compression levels, but these existing ones are good enough for a format designed as an interchange between video professionals; not for streaming or other final distribution. Whether Dirac is as good as ProRes or DNx in terms of file size/image fidelity I don't know but presumably it's near enough.

Share this post


Link to post
Share on other sites

I believe it's using existing open-source codecs such as Dirac, PNG and FLAC inside the new wrapper. AFAIK the new super-duper codecs such as H265 are the future in terms of compression levels, but these existing ones are good enough for a format designed as an interchange between video professionals; not for streaming or other final distribution. Whether Dirac is as good as ProRes or DNx in terms of file size/image fidelity I don't know but presumably it's near enough.

 

not an expert but my understanding is that this is correct. also EXR is one of the codecs in question (which does have compressions options) and that is most assuredly a production quality codec. the wrapper has fairly little to do with the compression aside from what codecs it supports.

 

one of the awesome parts of this whole thing is that it has the option to fold in more codecs in the future (h265 wouldn't cut it because it's proprietary).

 

long term I think the goal is to make something easy enough for people to use in most situations as to help make people less dependent on hardware manufacturers for their data.

Edited by foughtthelaw

Share this post


Link to post
Share on other sites

Cool, just read up on Dirac it looks pretty serious (i.e. I didn't understand a word after the first four pages of the spec) so good luck to them, this all sounds great.

Share this post


Link to post
Share on other sites

long term I think the goal is to make something easy enough for people to use in most situations as to help make people less dependent on hardware manufacturers for their data.

One will have to see. While the idea is sound, it all hinges on how manufacturers adopt it without burdening the user. You know, cameras don't record in OpenEXR or Ogg, so any conversions and conform will have to happen on ingest and any other import/ export operations more or less automatically. And I don't think supporting too many CoDecs is too good an idea. They all have their limitations an failings and have different implementations across programs and platforms. In the end, it will be the same mess and for your corrective MOX container to unfold its magic with all its nice LUTs, ICC profiles and metadata you still have to know how these things "tick" and implement pertinent routines and fixes - just like developers do already now with their native file handlers. It's not like they are promising to give you a single no-worries "export to MOX" button....

 

Mylenium

Share this post


Link to post
Share on other sites

you still have to know how these things "tick" and implement pertinent routines and fixes - just like developers do already now with their native file handlers. It's not like they are promising to give you a single no-worries "export to MOX" button....

 

 

you're dead right. this will have the same problem that ALL compression formats (and computer software for that matter) have which is user error. people will have to learn what the different flavors of exr compression do. same w/ Dirac. Prores got around that by just pre-canning their settings and calling them different names. There'll be an adjustment period, which is always uncomfortable for people. but all of these things appear (to me at least) to have well established protocols where some smarter (looks at Mylenium) can say "no you idiots, just do it like this" which is usually how people learn to use this stuff anyway.

Share this post


Link to post
Share on other sites

Not arguing your point, but I as a user should not even need to think in terms of CoDecs or compression settings, more like I get from program A to B with a maximum of my data remaining editable and looking the same on both ends. You know, it's 2014, not 1998... The simpler this is in terms of user interface, the more likely is it to succeed IMO. And I really don't want to worry about any of the internals. Since it's aimed at professional use, anyway, what would be the damage in simply setting for a fixed EXR flavor and FLAC audio in 24bit with all available channels? I'm sure we all have big enough disks to store such files and as long as MOX ensures a clean conversion across programs, why should it matter beyond that?

 

Mylenium

Share this post


Link to post
Share on other sites
Since it's aimed at professional use, anyway, what would be the damage in simply setting for a fixed EXR flavor and FLAC audio in 24bit with all available channels? I'm sure we all have big enough disks to store such files and as long as MOX ensures a clean conversion across programs, why should it matter beyond that?

 

Yeah that's the thing. If people know what they're doing and can take the time with LUTs etc. the solutions are already out there. The challenge is to have something simple, reasonably idiot proof that works simply. I like the idea of a few fixed flavors/presets the way prores operates, and maybe you can have an advanced tab for the people that do want to dig deep and start playing with settings.

 

Honestly almost all I ever really need is prores 4444 and then something lighter like h264 for client reviews/web delivery. Something that worked reliably cross platform, maintained color fidelity and could deliver just those two levels of compression would be gold to me.

Edited by anothername

Share this post


Link to post
Share on other sites

Yupp, exactly the point. Even if you work with many different systems/ collaborate with different people and facilities you only ever need a specific subset of formats and options....

 

Mylenium

Share this post


Link to post
Share on other sites

Yupp, exactly the point. Even if you work with many different systems/ collaborate with different people and facilities you only ever need a specific subset of formats and options....

 

There's a comment section on the indigo page. you should totally make that point so it get's prioritized.

 

if 5% of this things capabilities are what 90% of the people out there need that should be the first thing to get made. I'd love to see a "MOX_D_4444" preset in premier / AE.

Share this post


Link to post
Share on other sites

There's a comment section on the indigo page. you should totally make that point so it get's prioritized.

I don't really have any priorities in this. For now it's merely an interesting diversion to observe and theorize about. The real battle will begin when there's a definitive spec available...

 

Mylenium

Share this post


Link to post
Share on other sites

Sounds reasonable, if a bit too "programmer-y". And IMO it's still too complicated. That part about limiting CoDec selection based on bit-depth and a few other things, you know. That's just not how people think about this stuff...

 

Mylenium

Share this post


Link to post
Share on other sites

I'm well aware of the technical trappings and I give credit to the MOX people on that as well. It just serms to me that at this point everyone wants MOX to become a reality, but nobody actually has a clue how to do it and that ultimately is a huge concern. This could take another five years or so before anything comes of it. Again, I remain extremely skeptical. Some more ponderings from another angle on my blog:

 

http://myleniumblog.com/2014/10/27/the-mox-snafu/

 

Mylenium

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...