YUY2 capture quality much worse than MJPG

[mgu2]

The deinterlacing is turned off when you capture in MJPEG, but when you capture in YUY2 it stays on. What you get is a totally blurred video. I wonder why nobody noticed that yet? Maybe because it is less noticable in lower resolutions? I use PAL 704x576. Just in case I am the only one seeing this, I have Marvel G400TV. Different versions of VTools didn't seem to help. If you are going to compare the two formats, try to capture a full res video with sharp edges (titles, etc.). The difference between MJPEG and YUY2 should be instantly visible. MJPEG is much sharper compared to YUY2. I know Matrox does not support the YUY2 format and that is probably the reason why it is not properly implemented.

[Flying dutchman]

Isn't this just a playback issue? what if you simply convert your YUY2 clips into MJPG, don't the artefacts disappear then?

[mgu2]

It is not a playback issue. Compressing what you see on the screen can help nothing. See the following images:
http://www.idrive.com/id200/files/Shared/mjpeg.jpg (4kB)
http://www.idrive.com/id200/files/Shared/yuy2.jpg (4kB)


The difference is quite obvious. It is the deinterlacing in work, for sure. I have compared the YUY2 capture with the deinterlaced overlay image and they are identically blurred. Ever noticed that the deinterlacing is switched off when MJPEG capture is activated? This is not done when capturing to YUY2.

[mgu2]

Sorry, thanks to the stupid i-drive you cannot access the images. The geocities should be OK:
http://www.geocities.com/mgu222/yuy2.jpg http://www.geocities.com/mgu222/mjpeg.jpg

[bastioned]

It happens to me something similar, but instead of YUY2, it´s MJPEG the codec witch gives me blurred image. Curious indeed.

[Michel Carleer]

Yes, I do have the same thing too. I already complained about this to Matrox, suggesting many months ago that it would be a not so bad idea to let the user select if he wants to deinterlace or not. To no avail.
What is even worse is that you will find the same deinterlacing artifacts if you capture pictures that are 352x288 (PAL) or smaller. Which tends to indicate that even when you ask for something with a vertical resolution less than one field high, a full frame is captured at full res, deinterlaced and then resized afterwards.
Michka


[This message has been edited by Michel Carleer (edited 05 September 2000).]

[Grigory]

I know Matrox does not support the YUY2 format and that is probably the reason why it is not properly implemented.

YUY2 format is primary capture format before the data is compressed in MJPEG codec. So, it IS implemented. But, direct use of YUY2 is not officially supported. May this be because that direct yuy2 output is not <u>properly</u> implemented?

Read my very old notice about RGB captures with Matrox RR_G at http://www.geocities.com/ResearchTri...trox_rgb.html.
Could it happen that resolution/deinterlacing issues of RGB captures remain the same for yuy2 format? Actually yuy2 format is always used for video capture, and then the data is converted to RGB in CPU.
The question remains - is single field yuy2 capture done before RGB conversion, or the conversion itself discards one field and resizes the image to full size?
I am not using RR_G now, so I cannot check this.

Grigory

[mgu2]

Bastioned, full-res MJPEG should not be deinterlaced. If it is, you should maybe try reinstalling the video tools. Does the video picture on your monitor get sharper when you start MJPEG capture?

Michka, I fully agree with you. Nobody but the user should be able to choose if the picture is of inferior quality or not.

Grigory, I talk about YUY2 capture (see subject) and that is not properly implemented. The YUY2 capture code is present in the drivers, but looks rather like a quick hack - it is even hidden from users. Speaking of RGB, I wonder why Matrox put so much effort in RGB capture and not YUY2, which should be the easiest format to support from the programmers point of view. Considering the type of captured signal (PAL/NTSC), RGB is pretty inefficient compared to YUY2 4:2:2 format.

[bastioned]

Mgu2, I have tried 2 versions, 1.52 and 1.54 to no effect. Curious , when I had the MArvel G200 I didn´t have this problem. The answer to your question is yes, I get sharper image when I start the capture, but still not that sharper it should be. Like Michel Carleer, I too have another capture card, an Aver 98, this card doesnt have this problem, and I can definitely tell you that there´s a huge difference between both of them capturing full res. The Aver shows crisp and clear image while the RR-G shows some blurred stuff in my monitor that gives me stomack-ache, you know what I mean

[Michel Carleer]

Does anyone know at what resolution the RR-G (or the Marvel) actually captures snapshots or a movie? Does it depend on the asked resolution or is it a fixed 640x480 or 720x576 or whatever, with subsequent resizing? I too have a snapshot of the same picture taken with the Marvel and with the Pinnacle PCTV, showing a huge difference in sharpness. Unfortunately I don't have a site to show them. Is there another way to attach pictures to the messages on this forum?
Michka

[Dr Mordrid]

I do believe that snapshots are taken using the size of the PC-VCR preview window. If you have it set to .5x size then the snapshot will be half the clips size.

For a full sized clip (i.e. 704x480/576) this means it will be "delaced" and shrunk horizontally to 352x240/288.

Dr. Mordrid


[This message has been edited by Dr Mordrid (edited 07 September 2000).]

[Michel Carleer]

Sorry Dr Mordrid, I think I made myself unclear: The question was actually to know at what resolution the snapshot is actually digitized. Some cards will digitize at a resolution equal to the size asked for the snapshot, whereas others will always digitize at their highest resolution and then deinterlace/resize to provide the requested snapshot size. Some digitize a full frame if the snapshot size is greater than one field, and only digitize one field if it is smaller. I think the latter is the way the BT848 chip works. I am not sure about the BT878. What about the Zoran on the RR-G?
Michka


[This message has been edited by Michel Carleer (edited 07 September 2000).]

[Grigory]

mgu2,

Yes, I talk about yuy2 capture too. All videocapture cards work primarily in that format, because it is directly produced after difitizing the video signal:
luma component of analog video is digitized directly into Y values of YUV colorspace, and two decoded chroma difference signals are digitized with x2 less precision into U and V values. There is no way to make RGB capture directly - you always have to digitize in YUV colorspace, and then perform calculations to get RGB.
From any point of view this is actually done in all video capture cards. Then:
Cards like BT848 (and Canopus analog capture channel of DV Raptor for 4:2:2) can do RGB transformation in hardware, if you choose RGB format, or leave YUV colorspace as is, but make the output as 4:2:2, 4:1:1, 4:2:0, and even yuv9 (4x4 color subsampling) also in hardware;
Matrox card does RGB conversion in CPU, thus giving it 50-70% load.

The hack you are talking about is just the ability to let the card produce its natural YUV colorspace data instead of doing useless RGB conversion. My idea is that because this regisrty change only skips the RGB conversion, then it is possible that, as in the case of RGB captures, only single field is captured, and then interpolated to full size. This may explain the drop in resolution.
Do you see interlacing artefacts when capture in yuy2 format? If NO, I am correct. Please re-read my note.
I totally agree that RGB conversion is useless, because it is not only eating CPU power, but also reduces the color depth because of conversion. You can also search the forum for old-time discussions about of this topic about year ago.

Once again:
1. 4:2:2 digitizing (yuy2 fourcc code of format, if you wish), is done natively.
2. Full size frames are used for MJPEG compression.
3. However, it is not clear for me what is going outside the card when you force it to skip MJPEG compression. It depend on what way the data go a) skip MJPEG compression only or b) the card is working as in the case of RGB capture (single field) and only the YUV to RGB conversion is skipped.

BT cards capture single field if the frame height is less or equal the field height. Then they begin to add the lines from another field if you inrease the frame height. Finally, you get interlaced frame at full height.
No one card does "deinterlacing" after capturing full size internally - it cannot, as all of us cannot do this correctly. What the card does - better or less resizing of single or double fields for the output size.

Grigory

[Michel Carleer]

Grigory,
One additional small piece of information: the reason why cards capture in YUV is mainly because YUV is the format used by TV to transmit the picture. This format was invented so that old B/W TV sets could still be used, dealing with only the Y component.
And a small correction: going from YUV to RGB does not reduce the colour space. YUV is 24, 16 or 12 bit, whereas RGB is 24 bit. However, it introduces errors because the Y, U, V and R, G, B components are each coded in a one byte variable (only 256 distinct values) at most. One YUV value will generally be transcoded in R, G, B values which are not integer values and thus will be approximated by the closest integers.
Michka

[mgu2]

Bastioned, it seems you are concerned about the quality of the on-screen picture. The overlay image is indeed not 100% sharp even if you capture MJPEG. This is due to the cropped image. Input video is resized and filtered (blurred) to fit in the capture window you see on the screen. If you set the capture window to 704x576, the image is still cropped because the driver needs to remove the black borders caused by vertical and horizontal blanking. The result is that one pixel on your monitor is not equal to one pixel of input video, therefore, overlay image quality is low. Fortunately, this does not affect capture quality. Try viewing a captured AVI in MediaPlayer while PC-VCR is active.

Grigory, I know that internally the card works with YUV, therefore it suprises me that Matrox did not bother to allow users to capture in YUY2 - it should be straightforward. The YUY2 capture code is probably not a mere skip of RGB conversion as the capture drivers contain a dialog that allows for selection of YUY2 frame size. Maximum RGB frame size is 640x480 (which is stupid) whereas it is 704x576/480 for YUY2.

Do you see interlacing artefacts when capture in yuy2 format? If NO, I am correct.

Of course, I do. That's why I started this thread! See the yuy2.jpg at the above URLs. The full-res YUY2 capture suffers only from the blurred image. The resolution seems to be good, i.e. both fields are captured.