From: "Allen Ellis" Received: from mail-ve0-f177.google.com ([209.85.128.177] verified) by media-motion.tv (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 5497830 for AE-List@media-motion.tv; Mon, 09 Jun 2014 20:14:11 +0200 Received: by mail-ve0-f177.google.com with SMTP id oz11so2277976veb.36 for ; Mon, 09 Jun 2014 11:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=mGA5POvJWmf9BH4hHsrcZURn3OqzSQli4UG/Irb3bxw=; b=nPrv3kVPaonlyFfcici6TnLNFI7bzPV53sp7d3omPXH/3YPc8PJJeR1e1X+PR4nQBd rj4GrHY4ss7g5EJAG48XRnQidspV49GZrGP2r2FPrDvMno3VCdIiEcWP/b5B89C0xsaJ u1gtxqbdF/axiCvh8pM1WmQdU9jFXZ61/dLMqgPl4Luh/ZllVVvBooodpiWyWDqoltvy KSSyQr20kGCSIsf5jRPHzBWS5h3GkOc78Mdm3aQka1nD9Mtqo7xHBnUvyI3Ax/VaaBZg 1/y8n2YWf8XhhKF7W/1XaAYfT9JmLfKlhBWXm2I3jxL7+q9VOMj2nFmONiwNKq+sl7cW iMSQ== X-Received: by 10.220.165.6 with SMTP id g6mr27226896vcy.17.1402337650197; Mon, 09 Jun 2014 11:14:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.182.104 with HTTP; Mon, 9 Jun 2014 11:13:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jun 2014 14:13:30 -0400 Message-ID: Subject: Re: [AE] Lossless movie format To: After Effects Mail List Content-Type: multipart/alternative; boundary=001a11c3576c7ecbe304fb6b2de8 --001a11c3576c7ecbe304fb6b2de8 Content-Type: text/plain; charset=UTF-8 I am super excited for what you are working on! Thank you for kicking this off! *Wish list:* - No gamma inconsistencies between platforms (I can't believe this is still unresolved!) - If the encoder crashes while rendering, or I begin to copy a file while it is transfering/still encoding, the rest of the file should still playable up until that point, not a completley corrupt file - Easily parsable information at the front of the file specifcying information like codec, bitrate, duration, etc - Can support bizarre frame/rates resolutions, to a great number of significant digits, allowing for future applications (DNxHD fails this terribly). *Bonus features:* - GPU-accelerated encoding - Support for low enough bitrates that devices like SD cards could record in real-time if they need to - Resiliant to corruption. Checksums could indicate possible problems but it would be nice if it could attempt to play anyway without crashing the player or totally failing - The ability to define a poster frame / thumbnail, or generally support thumbnails easily. (Windows Explorer still doesn't show thumnails for .PSDs for instance) - I love Steve Oakley's idea of embedding the codec in the file as an option. Genius. Could eliminate the need to distribute/install codecs for certain users - just load the codec into memory from the file and discard when done, if they choose to accept that performance tradeoff. *Brainstorm/crazy ideas:* - Meta data that could specify the file's history, or other useful information about where it came from. Obviously this needs application support, but for example: the name/path of the project file that originally rendered this file. Possible major privacy implications to address, perhaps should be off-by-default. - Possible "3d" support, allowing multiple, distinct images to be embedded in one file. Perhaps this is done by arranging each image side-by-side, but meta information could define distinct areas of the image with names (think concert LED mapping applications that have dozens of screens that need to play in sync) - Easy to add a description to the file, or preview the thumbnail/other metadata remotely. For example, if you are browsing an FTP share, it would be nice to download the first few hundred KB of a file only, so you can learn as much as possible about it, before commiting to a long file transfer. - Along that same line, imagine if you were able to embed proxies into a file. For some of our deliverables, I wouldn't mind spending a little extra render time and make the file a tiny bit larger if it meant easy previews from remote locations. --Allen On Mon, Jun 9, 2014 at 2:03 PM, Steve Oakley wrote: > codecs not installed is the #1 problem of QT, especially ProRes on PC, or > QT in general on PC. more of a problem with non-video types. > > #2 gamma problems. > > no one I work with uses OMF so I don't have those problems. > > MXF Folders..."smart" producers who pull the media files out of the > folders and hand those off :( but since this is going to be a single file > format, not a problem. > > > so really the big goals should be : > > no codec install problems - apps should natively support the format. > however, as BACKUP having a QT/AVfoundation component might also be a good > idea to get MOX files open in apps that due use QT but don't have native > support. this might be really important to small developer's that don't > have the resources of larger ones. > > auto code updates - part of the API should be that if the codec is > updated, the app can go pull it down from the web if its 1.2 and the file > content is 2.0. > > ************ >>>>>>> > > 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. > > ----------------------- > > enough metadata to also have good gamma / FPS / log curve / Camera viewing > LUT / TC interpretation by apps supporting the format. options like camera > info would also be good. > > S > > On Jun 9, 2014, at 12:15 PM, Brendan Bolles > wrote: > > > On Jun 8, 2014, at 12:05 PM, Louai Abu-Osba wrote: > > > >> I hadn't realized this picked up again. I'm so beyond excited. I think > MOX is a great name and I love the proposal. > > > > > > Thanks for the encouragement, Louai. > > > > I have a question for everyone: what have been your past struggles with > existing file formats that you hope to solve with MOX? > > > > In other words: let's hear your rant about QuickTime/AVI/OMF/etc. > > > > > > Your responses will help me with the Kickstarter video and other > messaging blah blah blah. > > > > > > Brendan > > > > > > +---End of message---+ > > To unsubscribe send any message to > > > +---End of message---+ > To unsubscribe send any message to > --001a11c3576c7ecbe304fb6b2de8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am super excited for what you are working on! = Thank you for kicking this off!

Wish list:<= /div>
  • No gamma inconsistencies between platforms (I can't believ= e this is still unresolved!)
  • If the encoder crashes while rendering, or I begin to copy a file = while it is transfering/still encoding, the rest of the file should still p= layable up until that point, not a completley corrupt file
  • Easily parsable information at the front of the file specifcying informatio= n like codec, bitrate, duration, etc
  • Can support bizarre frame/= rates resolutions, to a great number of significant digits, allowing for fu= ture applications (DNxHD fails this terribly).

Bonus features:
    GPU-accelerated encoding
  • Support for low enough bitrates that= devices like SD cards could record in real-time if they need to
  • Resiliant to corruption. Checksums could indicate possible problems but= it would be nice if it could attempt to play anyway without crashing the p= layer or totally failing
  • The ability to define a poster frame /= thumbnail, or generally support thumbnails easily. (Windows Explorer still= doesn't show thumnails for .PSDs for instance)
  • I love Steve Oakley's idea of embedding the codec in the file = as an option. Genius. Could eliminate the need to distribute/install codecs= for certain users - just load the codec into memory from the file and disc= ard when done, if they choose to accept that performance tradeoff.

Brainstorm/crazy ideas:
  • Meta data that could specify the file's history, or other use= ful information about where it came from. Obviously this needs application = support, but for example: the name/path of the project file that originally= rendered this file. Possible major privacy implications to address, perhap= s should be off-by-default.
  • Possible "3d" support, allowing multiple, distinct image= s to be embedded in one file. Perhaps this is done by arranging each image = side-by-side, but meta information could define distinct areas of the image= with names (think concert LED mapping applications that have dozens of scr= eens that need to play in sync)
  • Easy to add a description to the file, or preview the thumbnail/ot= her metadata remotely. For example, if you are browsing an FTP share, it wo= uld be nice to download the first few hundred KB of a file only, so you can= learn as much as possible about it, before commiting to a long file transf= er.
    • Along that same line, imagine if you were able to embed proxie= s into a file. For some of our deliverables, I wouldn't mind spending a= little extra render time and make the file a tiny bit larger if it meant e= asy previews from remote locations.



--Allen


On Mon, Jun 9, 2014 at 2:03 PM, Steve Oa= kley <AE-List@media-motion.tv> wrote:
codecs not installed is the #1 problem of QT, especially ProRes on PC, or Q= T in general on PC. more of a problem with non-video types.

=C2=A0#2 gamma problems.

no one I work with uses OMF so I don't have those problems.

MXF Folders..."smart" producers who pull the media files out of t= he folders and hand those off :( but since this is going to be a single fil= e format, not a problem.


so really the big goals should be :

no codec install problems - apps should natively support the format. howeve= r, as BACKUP having a QT/AVfoundation component might also be a good idea t= o get MOX files open in apps that due use QT but don't have native supp= ort. this might be really important to small developer's that don't= have the resources of larger ones.

auto code updates - part of the API should be that if the codec is updated,= the app can go pull it down from the web if its 1.2 and the file content i= s 2.0.

************ >>>>>>>

in fact here is an idea - Put the codec IN the media file as an option. thi= s would guarantee codec install problems would never be a problem. its a mi= nor bit of file bloat but if the actual codec code is a couple kb, even 50k= b 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 ope= ns up and extends to new codecs.

-----------------------

enough metadata to also have good gamma / FPS / log curve / Camera viewing = LUT / TC interpretation by apps supporting the format. options like camera = info would also be good.

S

On Jun 9, 2014, at 12:15 PM, Brendan Bolles <AE-List@media-motion.tv> wrote:

> On Jun 8, 2014, at 12:05 PM, Louai Abu-Osba wrote:
>
>> I hadn't realized this picked up again. I'm so beyond exci= ted. I think MOX is a great name and I love the proposal.
>
>
> Thanks for the encouragement, Louai.
>
> I have a question for everyone: what have been your past struggles wit= h existing file formats that you hope to solve with MOX?
>
> In other words: let's hear your rant about QuickTime/AVI/OMF/etc.<= br> >
>
> Your responses will help me with the Kickstarter video and other messa= ging blah blah blah.
>
>
> Brendan
>
>
> +---End of message---+
> To unsubscribe send any message to <ae-list-off@media-motion.tv>


+---End of message---+
To unsubscribe send any message to <ae-list-off@media-motion.tv>

--001a11c3576c7ecbe304fb6b2de8--