Flash XDR/nanoFlash Long GOP

[Dan Keaton]

Dear Friends,

In our testing, and confirmed by our customers using the Flash XDR, our Long GOP is relatively easy to edit, even on older, slower computers.

There is a technical reason for this.

Many people equate Long GOP with their editing experience with HDV or other non-full raster Long GOP implementations. It is vastly different when using our Long GOP recordings.

By "Full Raster", I mean full, pixel-by-pixel 1920 x 1080 (for 1080) or 1280 x 720 (for 720).

With HDV, it was not full raster; it was 1440 x 1080 (for 1080), which results in a Pixel Aspect Ratio of 1.333.

What this means, is that when your editor has to decode the images, it has a lot of mathematical processing to perform. The editor has to convert the 1440 horizontal pixels to 1920 horizontal pixels, so it has to calculate which pixel goes into which pixel.

The important point of this is that this requires computing power to accomplish this required task when using less than full raster compression.

Since we always record "Full Raster" (1920 x 1080 or 1280 x 720), none of this math has to occur. Each input pixel maps directly to an output pixel.

This is a main reason why our Long GOP works so well.

[John Richard]

The other quality issue in the Long GOP vs. I-Frame discussion that I've wondered about is related to the available total bandwidth and how the Long GOP decides to use up that available bandwidth.

With I-Frame the use of total available bandwidth is obvious - each frame treats every element of the picture equally; all portions of the picture are allotted the same data use for each frame.

But with Long GOP, the encoder looks at each element of each frame differently. It compares elements between frames. Those element between the frames that don't change, are assigned a much lesser data use. Those elements between the frames that do change are assigned more data use.

Wouldn't the Long GOP's assignment of more data use to changing elements and less data use out of the total available bandwidth to redundant portions of the picture elements allow it to improve quality over I-Frame?

In other words, if you only have a total 100mbps available for bandwidth, it would seem that assigning more of this available date rate to changing picture elements would provide more quality over I-Frame which assigns this total available data rate equally to all of the picture elements, whether they are redundant or not.

I am by no means an engineer, but it seems like when you are comparing equal total available bandwidths, intelligently deciding where to spend it would improve picture quality.

Is this assumption of the Long GOP algorithms correct?

[Mike Schell]

Hi John-
Your understanding is correct. In our analysis Long-GOP is about 2-3X more efficient than I-Frame only. That's why the 35 Mbps Long-GOP XDCAM EX has roughly (arguably better) quality than the 100 Mbps I-Frame Only DVCProHD.

Low bit-rate Long-GOP quality can suffer in high-motion situations, but with 50 Mbps (and certainly at 100 Mbps), these motion artifacts are basically eliminated.

99% of all video in the world is Long-GOP, since it is the defacto standard for DVD's, Blu-Ray and TV broadcast.

Best-

[Mike Schell]

Hi Dan-
Our XDCAM HD 422 CODEC (at 50 or 100 Mbps) also offers reduced CPU processing since the video is encoded in 4:2:2 instead of 4:2:0 color space.

So the elimination of the horizontal expansion (1440 to 1920) and color expansion (4:2:0 to 4:2:2) greatly reduces the CPU load as compared to HDV video. The net result is smoothly playback on 5 year old MACs. In fact, Matrox Axio users report multi-stream (3-4 streams) playback in realtime, using only the CPU to decode the video.

Best-

[Bill Ravens]

Out of curiousity, how does the Sony XDCAM HD codec compare to Apple Prores? AJA is touting their new Ki Pro recorder, but that system encodes to Prores, which is an Apple encoder, only.

disclaimer: I'm not wanting to start any platform arguments, just curious about Prores performance.

[Dan Keaton]

Dear John,

Based on our theories, and by thorough testing, there is more detail in images produced by our Long GOP 100 Mbps mode than any of our I-Frame Only modes including 160 Mbps.

I am going to state the theory differently than you did, but the conclusion remains the same.

For I-Frame Only (Intraframe Compression), each and every frame is allocated a certain amount of bandwidth (bit rate) to compress the frame. This can never be exceeded.

Also, each frame stands on its own. Even if the image is exactly the same as the previous image, or mostly the same, the compression starts from scratch.

But the most important part, is that if the image cannot be compressed within the allocated bandwidth, due to the rigid bandwidth budget for each frame, then detail in the image is lost.



With Long GOP, there are significant advancements that allow for higher quality (more image detail) under certain conditions.

The first frame of a Long GOP sequence is an I-Frame, but there is a significant difference.
If there is too much detail to compress the image in the bandwidth allocated to one frame, the compression continues using the bandwidth of the second frame.

This "magic" allows the first frame to use the bandwidth of two frames when necessary. Which in turn allows all of the detail in the first frame to be recorded without compromise.

Next, on subsequent image frames, only the differences are compressed. Typically with video (but not always) there is a portion of the image that is the same as the previous frame. The image could have been panned or tilted or both, but there is typically some similarity among the frames. If so, only the differences need to be compressed.


Also, please note that our implementation of MPEG2 always uses the same selected bandwidth, such as 100 Mbps, regardless of the frame rate.

Other Intraframe compression schemes may use 100 Mbps for 1080i60, but 1080p24 may use less bandwidth.


Now, putting all of the technical details aside, no one has ever complained about the image quality of our 100 Mbps Long GOP mode.

We handle extremely detailed images, along with lots of motion, either in the frame or with camera movement. It is very difficult to break our codec.

During NAB and other trade shows, we show a full-uncompressed image, live, from a good camera, using a good monitor while we are recording the images.

Then on playback, using our Long GOP 100 Mbps mode, no one has ever found an image defect. We get lots of comments about how clean our images are. Most cannot see any difference between live or recorded images.

[Dan Keaton]

Dear Bill,

I hope that this will appear to be fair and balanced, I certain intend it to be so.

We can safely say that Long GOP is more efficient than Apple ProRes which is I-Frame Only.

We can also reasonably say that our 100 Mbps Long GOP holds up to the most intense of technical evaluations. (But, Apple Prores HD at 220 Mbps may also.)

We have found that it is extremely hard to break our codec under any conditions and our quality seems to well received. I feel that Apple Prores at 220 Mbps also provides high quality.

Apple ProRes can record 10-Bit while we are 8-Bit. While this sounds like a major difference, and it may be to some; when technical experts compare 4:4:4 Full Uncompressed 10-bit to our 100 Mbps Long-GOP 8-Bit, the differences are very minor.

We do have an advantage in that our users can choose to record in native Quicktime or native MXF, so that the PC world can use our files.

Also, our users do have an advantage by having I-Frame Only and Long-GOP available as a menu option for each recording. And we support a wide range of bit rates and modes. From 35 Mbps 4:2:0 for long recording times, through 4:2:2 at 50 and 100 Mbps and 100, 140 and 160 Mbps I-Frame Only.

But overall, I think that it is fair that Prores at 220 Mbps will do a great job, just as our 100 Mbps does a great job.

It appears certain that both 145 Mbps and 220 Mbps Prores will create larger files than our 50 and 100 Mbps Long GOP modes.

Please remember that we think AJA builds wonderful, professional, equipment. This was presented as direct answer to your question.

[Bill Ravens]

Dan..

Thanx for your reply. Obviously, it is a slippery slope kinda question, so I'm greatful for the info. As someone who does a lot of color correction work, I look forward to your implementation of 10-bit uncompressed. I think this is the only place where 8-bit vs. 10-bit is noteworthy. I've been beta testing Cineform's FirstLight application , which allows color correction via metadata. The cineform DI is a native 10-bit codec, after conversion.

[John Quick]

The folks at Cineform tell me that their software converts M2T files to 10 bit I frames, but won't render out MXF files.

I'm using Sony Vegas, which (apparently) won't read the 160 mbps Nanoflash I frames. (And according to the posts above,the 100 mbps long GOP is better quality anyway.)

Any suggestions for highest quality recording, and then highest quality editing files, for nanoflash/Sony Vegas?

[Dan Keaton]

Dear John,

1. Sony Vegas, Sony Vegas Pro 8, will not, at this time, work with any of our I-Frame Only files. I have not yet tested Sony Vegas Pro 9.

2. Cineform at one time worked with our files, but not now, as far as I know. We do not know what happened. Obviously, in our development, we could have changed something that made it not work with Cineform.

We do work with many Non-Linear Editors.

3. Yes, our best quality mode is 100 Mbps Long GOP. This is a very efficient codec and produces just stunning images.

[John Quick]

Originally Posted by Dan Keaton

.... our best quality mode is 100 Mbps Long GOP. This is a very efficient codec and produces just stunning images.

Thanks for the reply, Dan.

I sure would like to find a way to arrive at 10 bit files (like the Cineform files), to maintain the higher quality through color correction, keying, etc. in post.

[Dan Keaton]

Dear John,

We would like for Cineform to take another look at our files and see if it would be possible for them to accept our files.

We will start another dialog with Cineform as soon as possible.

We have many sample files on our website ready for download.

The sample files are on our nanoFlash product page and our Flash XDR product page:

Convergent Design, experts in HDMI, SD, HD, and HDV

Convergent Design, experts in HDMI, SD, HD, and HDV

[Bill Ravens]

I've had a semi-chronic dialogue going on with Cineform over the issue of FlashXDR files being incompatible with CFHD. David Newman assures me that they will fix this issue as soon as they have time. In his mind, Flash XDR is a "corner point". Right now, this Cineform incompatibility is a roadblock to my use of the Flash XDR, since, my workflow is so dependent on being able to convert to CFHD. Hopefully, we'll get some attention from Cineform in the near future.

[John Quick]

Any updated information on Cineform/Convergent compatibility will be appreciated.

[Mike Schell]

Originally Posted by John Quick

Any updated information on Cineform/Convergent compatibility will be appreciated.

Hi John-
I know the Cineform guys are working on a solution. I'll give them a ring tomorrow and ask for an update.

Best-