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.

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?

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-

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-

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.

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.

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.

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.

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?

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.

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

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 (http://www.convergent-design.com/CD_Products_nanoFlash.htm)

Convergent Design, experts in HDMI, SD, HD, and HDV (http://www.convergent-design.com/CD_Products_FlashXDR.htm)

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.

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

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-

Hello everybody,

I'm really interested in the Nanoflash for my JVC GY-HD251. I also use Final Cut for editing. The question is : will i need to transcode from this long gop codec to an iframe codec to edit my videos, like i do it from HDV to Apple prores ? Or is it possible to grade or do compositing and special fx in Final Cut with your codec, at 720p50 ?

I do a lot of color grading, and from this, i export still images at this end.

Thanks.

Hello Fabrice,

I use a PC running Edius and I am able to edit the XDR footage straight from the CF card in a USB reader if I choose to.

In other words, the XDR files do not tax my quadcore 9450 based system.

Fabrice,

I know for a fact that you can record Quicktime files that do not need any re-wrapping/transcoding for you to edit them straight out of the nanoFlash into FCP.

Thanks for the answers,

What i wanted to know is if this XDcam long gop is good enough for grading or if (like hdv is) it's a good codec for capturing things but needs to be transformed in another (iframe) codec for grading.

Fabrice...

I think you'll find answers on both sides of the fence on this question. For my own preference, Long GOP, in any form, is not designed for editing, it is optimized for in-camera capture. Many people will argue that modern processors are fast enough to "decode" the IGPB mpeg2 encoding and allow editing. Personally, I believe you will suffer quality degredation by editing MPEG2 directly. My workflow involves transcoding the long GOP files into a Digital Intermediate(DI) before editing. Towards this end, I use Cineform, or any good 10-bit DI. However, at this point in time Cineform is not functional with the files from the FlashXDR. I believe both Cineform and Convergent Design are working the solution to this problem.

Another workflow for XDR/Nano Flash and FCP suggested by Tommy Schell of C-D is to set FCP to use Pro-Res as the renderer for any effects.

So effectively, the Long-GOP is left as is on the timeline unless an effect is used such as a transition of complexity - then FCP converts this complex portion of the timeline to a Pro-Res I-Frame section for swifter rendering.

There is also the options to set the boxes to capture in a couple of I-Frame formats at different data rates.

Finally, depending on the power of your Mac, the Long-GOP can be very workable. As has been pointed out, the Long-GOP used in the C-D boxes is far less computer intensive than HDV as there are less computations needing to be processed.

Fabrice...

I think you'll find answers on both sides of the fence on this question. For my own preference, Long GOP, in any form, is not designed for editing, it is optimized for in-camera capture.

I couldn't disagree more. You've probably never been editing on an Axio which leaves long GOP material in it's natve form, transcodes it on playback to 10 bit uncompressed that you can mix multiple layers of, all with RT colour grading.

David...

If you read my post carefully, you'll notice that I didn't say Long form GOP couldn't be edited. With today's fast processors, it can be edited, and edited successfully. At the risk of repeating myself, I'll say again that long form GOP is a capture format, not an editing format. The nature of mpeg2(aka long form GOP) is to record I frames, which serve as masters. The rest of the GOP are derivatives of the master I frame. When this is edited, the processor must reconstruct the video stream, perform the edit, then deconstruct the video stream. This is no simple task, but, it can be done.

I should have let your quote run on longer to this sentence.

Fabrice...
Personally, I believe you will suffer quality degredation by editing MPEG2 directly.

You certainly can get this on systems that transcode to compressed intermediate codecs and then add effects. You don't get this on the Axio workflow for the reasons I state above.

After reviewing matrox's website describing Axio, I see no supporting evidence that long form GOP encoding is handled any less lossy in Axio than any other DI system. Yet Axio costs $3500 with the dubious distinction of being tied to an Adobe Premiere platform. It seems Axio uses an I-frame MPEG2 DI, which is a little different than Long GOP MPEG2, altho' it IS an intraframe compression protocol. So, in effect, axio does not edit long form GOP, and it does edit a compressed DI's. I would submit that there is generational loss with I-frame MPEG2, that you do not see with full frame wavelet compression scheme DI's like Cineform.

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


Any new word on compatibility?

After reviewing matrox's website describing Axio, I see no supporting evidence that long form GOP encoding is handled any less lossy in Axio than any other DI system. Yet Axio costs $3500 with the dubious distinction of being tied to an Adobe Premiere platform. It seems Axio uses an I-frame MPEG2 DI, which is a little different than Long GOP MPEG2, altho' it IS an intraframe compression protocol. So, in effect, axio does not edit long form GOP, and it does edit a compressed DI's. I would submit that there is generational loss with I-frame MPEG2, that you do not see with full frame wavelet compression scheme DI's like Cineform.

Bill, you really should try to read things with a little more diligence. Many of your statements above are factually incorrect.

First. Axio does not use an I-frame MPEG2 DI. If timeline sections need to be rendered because of non-matrox effects they can be done in Iframe or uncompressed, 8 or 10 bit

Second, Other systems when importing long GOP will convert it to an intermediate codec or uncompressed in order to work with more than one layer, straight cuts. Axio does not. It will handle 4-8 layers of HD long GOP plus effects without any rendering depending on the processing power of the system. Then, when exporting long GOP, it converts it on the fly to HDSDI. Other systems need to render most effects, including color grading. Axio does not.

Third, Adobe Premiere is no more or less dubious than any other NLE. They all have their strong an weak points. And Cineform seems to use Premiere without complaints.

Fourth. If there is the necessity of rendering a timeline section if can be done in 10 bit uncompressed. I would submit that that's going to be better than any form of compreesion, wavelet or otherwise.

Any new word on compatibility?