2 Problems, G400-TV, Please see if you can help.

[Phire]

Ok, i've got 2 problems, im not sure if 1 is even a problem but i'll talk about it anyway. On my 704x480 captures I seem to get zigzag patters in some scenes, the patterns are especially visible on bright colors.

Here's what i mean:



And zoomed:



Is this the way it's supposed to be? I know the source looks bad in the first place, but it happens on all 704x480 caps from any source.

My 2nd problem now.. In virtualdub (Using its internal capture mode) I can't capture for a long peroid of time, I can get about 20 minutes and then an error pops up saying "AVI Cap Error: the parameter is invalid." I have no idea why it's saying that.. it pops up in the middle of long captures.

[Phire]

About the 2nd error, i've learned that it happens when the file hits 4 gigs.. then that error pops up.. there is more than enough space for the file, but i dont understand why it stops capturing afterwards..

If anyone knows a way to resolve this so that it can create files above 4gb please let me know, i've tried with virtualdub and MSP (both support OpenDML).

OR if anyone knows how to get either program to make split files then maybe i can get it to have 3gb chunks each.

[Phire]

Hmm, i've learned something again :P it seems windows fat32 cannot make files above 4gb (damn windows :P)

Ok, now all that remains is to find out if VirtualDub or MSP can make chunks, if anyone knows how it can please let me know. I'd use PC-VCR except the chunks it makes are different framerates (29.976, 29.970) thus not allowing an append.

Still need to find out about those patterns in 704x480 video too.

[Fyx]

The zig zag pattern is definately a problem and isn't supposed to be in your captures. I appear to be in the same boat you. About 4 months ago I picked up a g400-marvel and have had a strange problem with a checker pattern appearing in all my captures. Although it is difficult to notice, the pattern is also even viewable on the preview display while it is capturing, but it appears as more of a noise then a pattern there because it is constantly moving. It is also noticable in lower resolution captures, but appears only as a few thin vertical lines of a checkery effect in the final capture.

Here is snippet of a capture from my g400-marvel illustrating the problem.

-snippet from capture at 1x


-snippet from capture at 4x


As you already know this is a big issue for capturing things such as animation which typically have large areas of constant color.

I have since tried using different motherboards, removing all peripials, and essentially changing every single component but the g400-marvel a few times. In addition to trying different operating systems and versions of the driver. My best guess is that it is probably a physical defect in the card or the break out box of some type, but it must not be very common because until now I have not seen anyone else with the same problem yet.

When using other programs to capture such as Virtual dub and AVIO, I can capture without the problem when doing an rgb capture, but only after initializing it through the software then not touching mjpeg at all. If I try to capture in mjpeg until I reinitialize the card the checker pattern is present during all captures, even if I switch back to rgb. For me though RGB capture is essentially useless, as mjpeg is one of the reasons that I got the g400-marvel in the first place.

From the looks of things the only way to fix it is to replace the card. I've tried talking to Matrox tech support about it via e-mail a while back. They weren't very helpfull and seemed kind of hesitant to give me an RMA for it, perhaps I was just talking to the wrong people though. Every other marvel owner I've talked to has said the checker pattern is certainly not suppoesed to be there. If I had an extra few hundred dollars lying around I'd go out and buy another g400-marvel just so I could prove myself right and actually use my card for capturing. But that isn't an option since I'm currently a college student my finances are somewhat limited.

As for the problems you are having with making long captures, it is possible that they are related to the checker pattern. But I have not yet tried doing any long duration captures just because the checker patterns in my final captures are unacceptable and I have yet to resolve that problem yet.

If anybody knows the best way to get an RMA from a card through matrox please let me know.


John Helmke
jahelmke@students.wisc.edu
ICQ: 2087316

[Phire]

Ok, our situations differ alittle bit, but I can see yours is worse than mine.. You seem to get the problem with any MJPEG capture but for me I only get this problem with 704x480 captures. I can capture in 352x240 with no problem at all, or any other resoultion for that matter, its only 704x480 that does it.

Another difference.. You seem to have a checkerboard pattern where I have ZigZag patterns..

The patterns appear as soon as you start the MJPEG capture.. But as i said, they are only visible on some bright colors.

"but it appears as more of a noise
then a pattern there because it is constantly moving."

The patterns don't move for me, they stay still but sometimes in some extremely bright colors or extremely dark colors you just cant see the pattern.

"As you already know this is a big issue for capturing things such as animation which typically have large areas of constant color."

Yes, very visible over flat colors.

As for the long captures thing, they arent related, the problem was that windows cannot make files above 4gb no matter what, unless you use windows NTFS and not Fat32.

Also, if the 704x480 is reduced 2:1 (352x240) all patterns dissapaer.. right now i've been using a noise filter to get rid of some of the pattern marks, but that makes the video lose quality. Will someone please address this problem to Matrox.. If it is indeed a hardware problem then it is very serious as was the green line problem.

Also let me state again, it does not matter what source it comes from, even from perfectly clear sources the patterns can still appear.

[Phire]

Could Matrox be Hiding Secrets? I think i've made a few discoveries..

Here is picture #1, Taken with the snapshot tool.



THINGS TO NOTE: The Image Size.. 688x470.. Which probably equals to what the 704x480 picture would without the borders.. Does this mean 704x480 is just a scam? a 688x470 picture with borders? And the lines arent as sharp as MY MJPEG capture.. it looks alittle blurred.

IMAGE #2:



Well Looky here.. there ARE patterns in the video, after applying a sharpening filter over it 3 times. Does this mean Matrox applies interpolation over its 704x480 videos to prevent the problem i'm having?

IMAGE #3:



Hmm, almost looks just like the screencap right? all i did was apply a blurring filter over the messed up pattern image and it almost looks the same.. cept the borders are there and that weird distortion to the left (which doesnt bother me much).

So is our cards missing the ability to interpolate? I'm not really sure but thats what it looks like to me.. Also, there is some color quality loss when doing MJPEG.. but i think that is normal.. Anyway these are my theories and they look quite good at the moment.. I'd still like to know what the problem is, If someone can please notify Haig or Oliver or any matrox tech to read this forum post i would be most greatful, its quite a problem.

[Walrus]

Just as a note: I have noticed this problem on my system as well under any configuration. (Marvel G200) My solution is to use an adaptive bluring filter I wrote (2d cleaner). It blends a pixel with pixels around it that are close to the source pixel, so the sharp edges are retained. You may want to play around with it to see if it can clean up these problems. (it's freeware) http://home.earthlink.net/~casaburi/download/
Please let me know if it helps the problem. (it generally seems to for me)

[Phire]

Ok, while this problem remains unsolved for the moment, can anyone answer the other question i posted? I was looking to also find out how to make MSP or VirtualDub make chunks of 2gb files rather than use OpenDML, becuase it will stop at 4gb becuase of the Fat32 limit. I'd use PC-VCR but as i stated before, it does not make each chunk the same framerate as the last file, making it unable to append each file.

[Phire]

The major problem has been solved on the official Matrox Tech Support forum..

Haig had told me he gets the same patterns using animation, he used a marvel as well as a Miro card both at the same data rate and the patterns were still there.

It seems the Marvel's max data rate of 3mb/s is not enough to handle the video, becuase after he pushed the miro's datarate to 6mb/s all the patterns went away.

If you wish to read about it, its here: http://forum.matrox.com/mgaforum/For...ML/000320.html

Well, i'm glad that at least my card isnt messed up.. But now on to that other question I had which I KNOW people know the answer to, so why doesn't someone help me out? I need to know how to make VirtualDub or MSP make chunks instead of using OpenDML.

[Michel Carleer]

One idea: would it be that the pattern you see is the colour subcarrier frequency? It certainly looks like it.
PC-VCR applies filters (deinterlacing filters?) when looking at TV or playing back, but not when capturing. Look at a picture from the TV IN and then start capturing. The format has no importance except for picture size which must be > 352x240 or 352x288: under or at these resolutions, PC-VCR uses only one of the two fields for each picture; above these, the 2 fields of each frame are used to build each picture. The picture quality changes during capture (picture is sharper), and reverts back to the original filtered when stopping capture. It is especially noticeable on pictures with small text in it.
Michka

[Phire]

Well the investigation is still sort of going on.. So are you saying that its just a coincidence that it seems to remove the patterns over the image becuase PC-VCR's true purpose is for removing the interlacing and not the patterns?

Yes i noticed the picture gets a slight blur when initiating the capture mode.. And you can't see the pattern that much during its realtime preview mode for the capture.. As soon as I open it in virtualdub, which I know has its own internal MJPEG decoder, it then shows these patterns very clearly.

Haig had stated that it was a datarate problem but now im not so sure.. I know now for a fact that every single frame contains the pattern.. I thought if the datarate was limited only some frames that were hard to compress would have them? am I not right?. I think my proper output would be where I see the realtime preview window during capture.. becuase it looks pretty clear, and i can see it initiates some of the filtering, and i only see very LITTLE patterning. But when playing back a file the filtering applied over the patterns make it worse.

[Michel Carleer]

Yes, it is what I am suggesting: that the pattern is coming from the colour subcarrier, and that the filtering applied by PC-VCR when either showing TV or playing back a recorded clip removes the pattern. Now, I am absolutely not sure about this, it might well be some other sort of interference maybe with a frequency generated by the PC itself. I am also considering that it is not by increasing the data rate that the pattern disappears, but simply by changing the data rate or the picture resolution. What I am suggesting here is that some horizontal resolutions (or data rates) would reveal the subcarrier more than others because they would lead to some sort of frequency relation (harmonically speaking) with the subcarrier.
Once again, this is just an unproven idea. The only reason I am throwing it out is that I don't see such patterns on my european system. But I am using PAL format, not NTSC as you probably are, guessing from the picture sizes you mention. As you know, PAL and NTSC don't use the same subcarrier frequency (4.43 MHz versus 3.58). Additionaly, I remember seeing very similar patterns on TV sets which had poor colour subcarrier filters.
Michka

[Aryko]

And on a completely unrelated tack...

You could save disk space when capturing animation as the frame rate is typically 7.5 - 15 frames per second, so instead of capturing at 29.97 fps, try at 15 fps?

Wouldn't it be nice if you could use the extra bandwidth on the signal quality (if that made any sense).

- Aryko

[zathras2]

Hi, I have been having this exact same problem too, and was pointed at this thread so I shall resurrect it now.

I will try to summarize everything I have found so far:

1) The problem can be duplicated with other codecs or uncompressed RGB if one goes into VirtualDub and selects "preview" rather than "overlay"

2) When video is viewed in "Overlay" mode or captured in it, it somehow "smooths out" the ugly pattern imperfections we are seeing. This explains why a capture file that is played back with hardware acceleration does not show any signs of the "noise".

3) Matrox PC-VCR is supposed to capture in overlay mode, but it does not for me, or the others with this problem.

I have found something!

They finally got an SVHS vcr (Sony SLV-R1000) out here so I could test S-Video... and guess what I found...

Yup. Those patterns go away if I use the S-Video cable, rather than composite!!! (using the same VCR).

Here's a comparison:



Using Composite cable




Using S-Video cable


So please try it out and see if that does it for you. If you don't have an SVHS vcr at least try a source where you can get both composite and S-Video out (LaserDisc, DVD, or Dreamcast) to see if it works for you. If it does, you may just want to get an SVHS VCR (they're getting cheap, about $200 USD so no big deal).

[Michel Carleer]

zathras2,
Seeing your 2 pictures, I am now pretty dam sure the pattern is the colour subcarrier. In composite mode, luminance and chrominance are transmitted on the same wire, the colour information being phase coded on a subcarrier frequency of 3.5795 MHz for NTSC or 4.433619 MHz for PAL. To decode the picture signal the chroma and luma signals must be extracted from the composite, by the use of appropriate filtering techniques. If there is a problem with the filters, then part of the chroma subcarrier can well be extracted as luma information which will look identical to the pattern you show.
S-Video, on the other hand, transmits the luminance on one wire, and the chrominance on a second one, so there will not be any cross-over between luma and chroma.
Michka
Note added: The fact that the colour subcarrier appears so strongly can come from two causes: either the Matrox filters do not work properly, or the VCR over-modulates the subcarrier.

[This message has been edited by Michel Carleer (edited 01 August 2000).]