4:2:2 and Matrox RT2000

[Jerry Jones]

Questions:

a) Does MPEG-2 editing using the
Matrox RT2000 use the 4:2:2
color space instead of DV's
4:1:1 color space?

b) Has anybody actually "eyeballed" the
the difference between compositing in
4:1:1 vs. 4:2:2 and have you "really"
noticed a huge difference????

I've seen one lengthy, fairly knowledgeable
post from somebody who claimed the difference
was negligible.

[DrMordrid]

It uses 4:2:2@ML as per the C-Cube DVxpress specs.

How much of an difference there is between 4:1:1 and 4:2:2 depends on how much color information is in the source video. If the source video doesn't need all the color space available in 4:2:2 you might not even see an apparent difference. The situation is much like optimizing a palette.

Example: If a 16 bit image is shown on a 16 bit and 32 bit display is there a quality difference? No. The 16 bit image data fits intact into both color spaces. But reverse the situation and you might see some degradation.

The amount of degradation moving from 4:2:2 to 4:1:1 depends on how much the videos color data needs to be "massaged" to fit into 4:1:1's color space.

Dr. Mordrid



[This message has been edited by DrMordrid (edited 09-08-1999).]

[Jerry Jones]

Okay... so would it follow that if
you're using BorisFX for MediaStudio Pro,
for example, and your source video is
acquired from MiniDV... you might see
some advantage in the ability
of the video to "hold up" under the
multi-layer compression inherent in BorisFX
compositing/effects? If so, how much of
an improvement?

[DrMordrid]

First an elaboration of the first answer:

4:2:2 performs 360 color samples/line (half the sample rate for lumance) while 4:1:1 performs 180 color samples/line (quarter the lumance rate).

Even with this reduced space DV has about the same color bandwidth (1.5mhz) as delivered by a BetacamSP.

Moving on...

While MiniDV uses 4:1:1 color space what is often of more importance is that DV has error correction and concealment features. This makes it much less susceptable to recompression artifacting than other DCT based codecs like MPEG (1 or 2) or MJPeg.

The EBU/SMPTE working group did tests that showed no visible degradation for DV with CG effects out to 4 generations of recompression. They also reported little degradation out to 7 generations for "natural" video. That's a lot of generations in either case.

As long as your f/x software and card are recompressing to DV without transcoding to another codec like MPEG-2 you shouldn't have much of a problem.

This is a problem for the DC-1000 as it transcodes DV to MPEG-2 for editing and then back to DV for saving it back out. By the time you load & save a DV project you've used up 2 generations of recompression already.

The entire report can be downloaded at:

http://www.ebu.ch/pmc_es_tf.html

Dr. Mordrid



[This message has been edited by DrMordrid (edited 09-09-1999).]

[Jerry Jones]

Thanks, Doc. Very helpful info!

[Grigory]

Hi Jerry,

The problem you are asking about in NOT with recompressions.

Imagine you have 4:2:2 uncompressed movie, FourCC code YUY2 (supported by Intel indeo drivers). You are asking about the difference between this format and 4:1:1 (FourCC code BTUV) format.

In most software editors, the frames are decoded into RGB color space, and then the effect or compositing is done on those RGB bitmaps.
The compositing effect itself is calculated with one pixel precision, as if both frames had 4:4:4 colorspace. This provides the best precision. Then, the output frame is converted into 4:2:2 or 4:4:4 colorspace.

There are two stages where you can get reduction in accuracy:

1. Two original frames have groups of 2 or 4 pixels with the same chroma components values. The compositing effect code thus has 2 or 4 pixel ambiguity in determining the contour of the same color.

2. Conversion from RGB to YUV colorspace. Because of 2 or 4 pixels must have the same Y and V values, this introduces additional errors that reduce chroma components effective bandwidth.

If you only convert 4:2:x movie to rgb, make transformation like one pixel shift, and convert back, you will lose some of effective color bandwidth because of two conversions. Compression itself may be nearly lossless, but you get color washing after some generations.

You can experiment with Intel Indeo video raw 4:1:0 (a group of 4x4 pixels has the same color) format. It is uncompressed, but has reduced color sampling frequency. The picture looks almost perfect for first conversion, but if you re-render the clip several times, you see color components "diffusion". The codec is available inside Indeo set of codecs.

In RT2000, all editing is done in YUV colorspace. This means that all effects are calculated without YUV to RGB and back conversions. Y, U, and V components are used directly. However, there is still 4:2:2 to 4:1:1 or 4:2:0 conversion when you render the movie to DV format. Multiple conversions will reduce the color components bandwidth exactly in the same way as in the case of RGB to YUV and back conversions.
What can help, is to use any of 4:2:2 colorspace formats (compressed or uncompressed) to store intermediate results. In this case you get the highest possible precision.

See also:
http://www.chumpchange.com/parkplace...rs/dv-beta.htm


Compression is basically not a problem for DV format. However, it may introduce artifacts that influence compositing also. From this point of view, 4:2:2 format video of the same bitrate has higher level of compression than 4:1:1 video. So, 4:2:2 colorspace compressed video may have higher compression artifacts level.

I assume that the editors like Premiere always work with RGB bitmaps inside the bulit-in processing modules.

If you have any information that some of built-in filters inside editors work in YUV colorspace, please correct me.


Grigory

[DrMordrid]

Grigory,

Thanks for confirming that recompression is not as big a problem with DV as with other codecs.

His question was smack on the issue of recompression D. He is applying multiple filters and doing compositing. As such those frames will be recompressed, perhaps several times. The capacity of DV to handle this given it's 4:1:1 colorspace was the precise issue. Answer: it can.

As for MPEG-2/4:2:2 and it's ability to handle this: it's not as good as DV. Since MPEG-2 has no ECC system you get visible errors every time recompression is performed, and their effect is cumulative. In a couple of generations this can become intolerable. MPEG-2 may have a larger colorspace, but those recompression errors are can be murder.

That litany of transforms you're talking about happens all the time in editors, no matter the original codec used. His results should be similar to what he's already used to minus the recompression errors caught by DV's ECC system.

You end up with a net gain in quality overall.

Dr. Mordrid


[This message has been edited by DrMordrid (edited 09-13-1999).]

[Grigory]

Dr. Mordrid,

Yes, I said that recompression does not introduce visible artifacts in DV. However, because of multiple RGB to YUV conversions and limited accuracy of DCT transforms you can get some color shift. It depend on the codec. My experimenting with Canopus and Adaptec codecs show some shift and reduction in color purity on 5-7 generations. So, I can easily accept 3-4 generations in my editing without noticeable change in quality.

I thought the question was about what Matrox advertized as an advantage - you can stay in YUV colorspace and escape colorspace conversions while editing.
Note that 4:2:2 to 4:1:1 conversions are much better that yuv to RGB and back.

Compression artifacts is another story. I tried to make MPEG2 files of 5000 kbit/sec, according to what Matrox said as DV to MPEG2 space-saving advantage. I tried bbmpeg and PixelTools Mpeg Repair software. I tried to make i frame mpeg2, and all combinations listed in C-cube chip specifications as supported for realtime Dv to mpeg2 transcoding. Yes, I could get very good video quality, but no one format/encoder could produce completely artifact free video.
Another software compressors like DVMPEG or LSX could not come close to what bbmpeg can do.

DVMPEG encoder is only fast.

LSX encoder cannot produce artifact free video with high motion and high level of details, like a clip with a lot of flowers under moderate wind. I think the problem is in motion estimation. If I set the slowest motion estimation mode, the picture quality improves to the level achieved by bbmeg with the motion estimation vectors length set to provide the same encoding time per frame.

High level of details or high motion video could not be compressed well from 25 mbit/sec to 5 mbit/sec with GOP values 1-5. I don't think that c-cube chip has significantly better compression technique. So, multiple recompressions will definitely degrade the quality starting from 2-3 generation.

ECC - it is error correction code? How it works to escape artifacts? If there is another meaning - please explain.

I thought that ECC data is used to recover bad bits while reading the video data from tape media. It is not used when you store video on hard drive, which always has internal ECC for all files.
In PC hard drive, any data file is either read without errors or not. If the drive electronics cannot read or recover single bit, a reading error occur. It is common for both DV and MPEG2 files stored on hard drive.

Grigory.

[DrMordrid]

Yes, ECC means exactly that.

DV does some degree of error correction and concealment. VERY basically if an artifact is trapped DV will do one of two things:

1. average the surrounding pixels and fill in the artifact with this data.

2. pull pixels in from the surroundings to fill the artifact. Kind of a "smear" function.

This is the primary reason DV doesn't suffer as much visible artifacting from multiple generations of recompression as other DCT codecs do (MJPeg, MPEG (1 & 2) etc). It hides them. It's not a very sophisticated ECC feature but it's enough to give it an advantage.

Of course this can also present a problem:

IF the errors accumulate to a high enough level the ECC features can be overwhelmed. When this happens the codec "falls off the cliff" and can create massive artifacting in the affected frames. This is the sole weakness of the scheme. It's rare but possible.

Dr. Mordrid





[This message has been edited by DrMordrid (edited 09-15-1999).]

[Grigory]

"VERY basically if an artifact is trapped ..."

Well, this is a key point. Do you know HOW to detect compression (not storage media data loss) artifact?
I think your explanation simply does not work for compression artifacts.

The explanation which you can find on the WEB is in following citation:

In MJPEG the quantization factor is chosen with a unique value for the whole frame. (Worse, most MJPEG algorithms compute this value against the preceding frame's data, which may not give an optimum quantization value for the current frame.) In DV, the DCT data of the whole frame are subdivided in 270 video segments (in 525/59.94 video). Each video segment is further subdivided into 5 areas called "macroblocks". The DV specification allows every macroblock to have its own quantization value. This means that a DV frame has 1350 quantization values which can be defined, vs. the 1 quantization value for an MJPEG frame. This is why DV is a lot better than MJPEG for the same data rate; DV allows fine tuning of individual parts of the frame.


Read the whole story at http://www.adamwilt.com/DVvsMJPEG.html

I don't see any ECC issues here. I did not try to read a blue book, however, it is clear from the document that the standard defines only a frame for DV coding.

ECC handles only error that occur on data reading from media.
There is also error handling technique , which compensate unrecoverable data losses by substitution or interpolation, using the nearest good data chunks. It is not a ECC, but a way to escape visual glitches on playback.

Grigory.