View Full Version : Motion JPEG 2000 in the Odyssey 7Q+?


Jack Zhang
August 11th, 2016, 11:47 AM
One thing the portable recorder market hasn't really touched on is Motion JPEG 2000. More commonly seen as an archival format, it would make sense as an acquisition codec, but nobody has really stepped up to implement it as it might be resource intensive.

Does the 7Q+ have the power for in the very least 1080p60 Motion JPEG 2000? JPEG 2000 is supported in the MXF format, but can also be recorded as a data stream as .mj2 files in a container similar to Quicktime and .MP4, but not identical.

Having Motion JPEG 2000 in the Odyssey might change perceptions of Wavelet codecs in portable recorders. I'm only here to give the consideration of implementing it into the Odyssey.

Dan Keaton
August 12th, 2016, 06:23 AM
Dear Jack,

At this time, we have not investigated adding Motion JPEG 2000 to our Odyssey.

Respectfully,

Gary Huff
August 12th, 2016, 06:53 AM
Having Motion JPEG 2000 in the Odyssey might change perceptions of Wavelet codecs in portable recorders.

In my opinion, DNxHD in MXF is a far more pressing issue that MJPEG 2000. Even Cineform would be better. I don't encounter MJPEG2K in the wild, and MJPEG already exists in the form of ProRes.

Jack Zhang
August 12th, 2016, 12:07 PM
All I'm saying is all recorder companies are heading down a dangerous path that if one or both of the companies should falter, the format goes down with them. We need an openly implementable wavelet codec before Apple shuts it's doors to professionals and Avid closes shop.

At this point, something from the JPEG-LA instead of the MPEG-LA seems more reasonable.

Gary Huff
August 12th, 2016, 12:10 PM
All I'm saying is all recorder companies are heading down a dangerous path that if one or both of the companies should falter, the format goes down with them. We need an openly implementable wavelet codec before Apple shuts it's doors to professionals and Avid closes shop.

The threat of that is virtually nil. Apple is not going anywhere and DNxHD is a SMPTE VC-3 standard.

Jack Zhang
August 12th, 2016, 12:17 PM
The threat of that is virtually nil. Apple is not going anywhere and DNxHD is a SMPTE VC-3 standard.

10 years down the line, would that answer still be the same? Imagine if the Library of Congress archived in ProRes and years down the line Apple goes out of the professional video business.

Open standards prevent that thing from happening. No one has been willing to give them a chance though, and since recorders have moved off of MPEG-LA standards, it's really concerning we have codecs not made by an experts group being so widespread.

Case in point: Who still uses Sorenson Video as a codec? Nobody.

Gary Huff
August 12th, 2016, 02:31 PM
10 years down the line, would that answer still be the same? Imagine if the Library of Congress archived in ProRes and years down the line Apple goes out of the professional video business.

Odd, because QuickTime is an acceptable format for the Library of Congress. Where are you getting this idea?

And the fact that you will poo-poo SMPTE VC-3 and point to MPEG-LA as an example of "open standards" is totally ludicrous.

You should really research this topic more.

Jack Zhang
August 12th, 2016, 04:43 PM
MPEG-LA had better longevity. MPEG-2 is still in use today as a legacy system. I'm not making the point that the MPEG-LA are open. In fact, they're the complete opposite of open. The fact you would go out of your way to interpret my words as DNxHD is inferior to a closed standard is frankly insulting.

My point is longevity, and thus ProRes is unproven and is now at risk due to already weakening support for it from it's manufacturer Apple. Once the recorder companies moved off of standards made by experts groups instead opting for ProRes, I became extremely skeptical cause of the nightmare Apple has caused, and is continuing to cause for PC NLEs.

JPEG 2000 has been around since... well, the early 2000s. It's an open standard and it hasn't gone anywhere. In fact, it's been standardized in archival and DCP delivery.

Quicktime as a CONTAINER is accepted at the Library of Congress. ProRes is only partially documented by them and this causes it's draft status to remain preliminary. Apple won't give up those specifications.

Someone seriously just needs to adopt a royalty-free, open implementation wavelet codec that has wide NLE support. Dirac tried to be that, but nobody gave a damn. (Even though it's standardized as SMPTE VC-2)

Gary Huff
August 12th, 2016, 04:53 PM
I'm not making the point that the MPEG-LA are open. In fact, they're the complete opposite of open. The fact you would go out of your way to interpret my words as DNxHD is inferior to a closed standard is frankly insulting.

I don't have to go out of my way to do that. You have made that point. You want CD to work more on MotionJPEG 2000 than their DNxHR implementation because you said that it was more important. You asked if 10 years down the line my use of DNxHR in an OP1a MXF container would still be appropriate, thus you think it is not. That you have changed your position suddenly is a reversal from what you have explicitly stated up to this point.

I became extremely skeptical cause of the nightmare Apple has caused, and is continuing to cause for PC NLEs.

Nightmare? What nightmare? What are you talking about? Premiere and DaVinci Resolve both now support ProRes decoding under Windows without the use of QuickTime. Did you not know about that?

Quicktime as a CONTAINER is accepted at the Library of Congress. ProRes is only partially documented by them and this causes it's draft status to remain preliminary. Apple won't give up those specifications.

And yet Adobe has those specs to decode, so does Blackmagic. Atomos, Video Devices, and Convergent Design can write out compliant ProRes files. So where do you get the idea that ProRes is "partially documented" and where are you reading that this is the case with the Library of Congress? Or are you merely assuming this?

Jack Zhang
August 12th, 2016, 05:17 PM
Wow.

Dude. I'm NOT trying to divert their attention from DNxHD. I'm making a point the solid state recording industry needs to hear.

Anyone from the engineering team, double down on efforts with DNxHD, but make your next goal another openly implementable and royalty free wavelet codec.

I know Premiere and Davinci have native ProRes decode now. By your terms that would ALSO divert attention from implementing DNxHD.

Yes, the companies that have been licensed by Apple can spit out compliant files, but just cause a lot of companies have it doesn't mean it's 100% open. They likely all had to sign NDAs to use the codec.

Gary Huff
August 12th, 2016, 05:43 PM
Dude. I'm NOT trying to divert their attention from DNxHD. I'm making a point the solid state recording industry needs to hear.

The "solid state recording industry" (what does that even mean? Every single camera I have used since 2008 has used solid state recording media) needs to hear MXF and have singular focus on supporting OP1a recording instead of the constant QuickTime wrapper nonsense. It was what I explicitly told every single recorder manufacturer at NAB this year. That's the main point they need to focus on, and a 16 year old codec implementation is a distraction and nothing more.

Anyone from the engineering team, double down on efforts with DNxHD, but make your next goal another openly implementable and royalty free wavelet codec.

It took C-D nearly a year to get ProRes on the Odyssey, so why not wait until after DNxHR has arrived before even starting talking about JPEG 2000 or Cineform or LongG MPEG-4 or whatever else is your heart's desire?

Besides you asked me:

10 years down the line, would that answer still be the same?

In response to my assertion that Apple was going nowhere and that DNxHR is a VC-3 SMTPE standard. So now DNxHR is fine. Yet you brought up AVID closing down, as if you don't understand what I meant by a SMPTE standard. So you did some further research and are now making it solely about ProRes? I cannot keep up.

I know Premiere and Davinci have native ProRes decode now. By your terms that would ALSO divert attention from implementing DNxHD.

Not really because they don't have writing yet. That is still something to consider. Once full ProRes implementation is on the Windows platform, it will become moot, but until then I'd still prefer DNxHR in OP1a for an assortment of reasons (smart rendering is one). Also, Apple could, at any time, make ProRes fully open source just like they did ALAC a few years ago.

Jack Zhang
August 12th, 2016, 06:06 PM
I agree with OP1a. This is one point we can agree on cause Quicktime nonsense is rampant in the SSD recorder industry and it needs to be fixed.

You can still suggest something for consideration. This isn't communist China where you're gagged from stating stuff for consideration.

A Redditor in the industry made a comment that made me suggest this to the CD crew: It never caught on in the acquisition world because nobody in the post world really supported it. And then they went and invented their own solutions, like DNG and REDCODE and whatnot.

As far as hardware goes, J2K encoder cores are out there, these guys make one that does 8k at 60FPS, (http://www.intopix.com/products/index/index/id/26/lang/en) up to 8GbPS, at 12-bit color in 4:4:4 at YUV, RGB, or XYZ.

But honestly, I'm not looking at this from an acquisition standpoint. Camera manufacturers have been inventing their own standards and storage systems since tape went out of vogue and Sony came up with XDCAM. Camera manufacturers are going to use whatever gets them the highest quality while fitting within the rest of their design constraints (size, power consumption, heat generation, etc). They really don't give a shit about standards compliance, because NLE developers have given them the tools they need to adapt the NLE to work with their media, so they can build their standards to meet the needs of the camera, not the needs of the post house.

And disk recorders like your Ninjas, HyperDecks, and KiPros I don't expect to change either as a huge part of their evolution has simply been convenience. Trace their lineage back and you'll find their roots in the FireDrive, which all it did was just cut out the need to ingest from tape. Now days it also offers the convenience of lower compression, but that's kind of inherent in reducing ingest time.

I don't even expect things to change at the mezzanine level. Speed and ease of decoding always trumps most other concerns, and once it's in the system who cares whose proprietary codecs you're using, it's in. Hell, look at Grass Valley and their HQX codec they use in Edius. I don't expect that to change either.

Where I would hope J2K would catch on is in archival and interchange. If a client is going to send me a bunch of material to work with that isn't a camera raw, it would be nice to have it in a vendor-agnostic format. Same thing for storing media. Back in the day you could put a tape on a shelf and know that if you came back to it in 20 years any deck that says "D5" or "DVCPro" on it, no matter who built it, will read that tape. Now I can't put a file on a disk and say the same thing.

Sure, today Apple is letting Windows users decode ProRes, but what about in ten years, after QuickTime 7 moves from "obsolete" to ancient. Will you even be able to install QuickTime on a PC in ten years, or will it be incompatible with the OS? DNxHD I feel a bit better about because it is a SMPTE standard, but the way they're hemorrhaging money is Avid even going to be around in ten years? Are we going to be sure that someone is still going to be making a 100% spec compliant and properly licensed encoder/decoder for DNxHD and DNxHR then? Or what about the old stuff from the Meridien days, how is that supposed to be stored?

That's why I'd really love to see J2K take a foothold. ISO standardized, encoders and decoders already exist (though in various incompatible ways), it meets the needs of long term storage, and it's high quality.

Also, A SMPTE standard means the codec is "open," yes. But Avid currently still holds control on implementations of the codec for hardware devices. My interpretation of open is something like Google's VP9 or the upcoming NETVC AV1, meaning the source is readily available and anyone can implement it with no gotchas.

There are strong examples where big companies have refused to open source something that has become widely used. Take for example exFAT. Owned by Microsoft, the SD card association adopted it in their SDXC standard which means all kinds of headaches for people on Linux cause the source is not openly available and the whole thing is protected by multiple patents. FAT32 isn't this way. Also, Linux can't be like "Well, just adopt it you lazy bastards." due to the nature of they will be sued out the ass if they included proprietary elements with base packages.