RR-G/MSP 5.2 Capture Problem (Long Posting)

[DAS]

The story so far ...

Our hero has purchased a G400 DH with a Rainbow Runner G-Series, has loaded the latest drivers (5.30.007, 1.51 respectively) and has managed to get most things working but is having difficulty doing video capture from a VCR. He's taken the advice offered and checked the "Tips & Tricks" section at idiots-guide and now needs more help.

The equipment:
PIII-500, 128Mb, Adaptec 2940U2 SCSI Controller, Seagate 18Gb LVD SCSI Drive, SCSI CD-R (36x) & SCSI CD-W (8x), IDE DVD & IDE ZIP, Creative SB Live 256 Value, USB Scanner, 2 x LG Studioworks 775N monitors, Intel Pro/100 NIC, G400 & RR-G

VCR: Panasonic NV-HD670
OpSys: Win98 SE
Software: MediaStudio Pro 5.2
Computer and VCR sitting on an APC SmartUPS 700.

IRQ Usage Summary:
00 - System timer
01 - Standard 101/102-Key or Microsoft Natural Keyboard
02 - Programmable interrupt controller
03 - Communications Port (COM2)
04 - Communications Port (COM1)
05 - Creative SB Live! SB16 Emulation
06 - Standard Floppy Disk Controller
07 - Printer Port (LPT1)
08 - System CMOS/real time clock
10 - IRQ Holder for PCI Steering
10 - Intel 82371AB/EB PCI to USB Universal Host Controller
11 - IRQ Holder for PCI Steering
11 - Matrox Millennium G400 DualHead - English
11 - Creative SB Live! Value
11 - Adaptec AHA-2940U2/AHA-2940U2W PCI SCSI Controller
12 - PS/2 Compatible Mouse Port
13 - Numeric data processor
14 - IRQ Holder for PCI Steering
14 - Intel(R) PRO/100+ Management Adapter
15 - Intel 82371AB/EB PCI Bus Master IDE Controller
15 - Secondary IDE controller (dual fifo)

Btw, I am located in Australia which has two major implications:
1) Video format is PAL and
2) All this gear was expensive (compared to US prices)

The problems:
I've had problems with video/audio sync but these have stopped (not sure why but I'm not going to argue).
The system used to lock at the end of a capture but I figured out that Power Settings and turning off the monitor were to blame for that. Now set to 60 minutes of idle time.

I am tring to capture at
Video: 25 frames/sec, MJPEG CIF (352x288 PAL) high quality 1.172Mb/sec
Audio: PCM 44100 Hz, 16 Bit Stereo

I keep getting "glitches" in the capture file. Never in the same place twice so I'm not blaming the tape. A "glitch" appears as a frame of unusual colours and a "blocky" picture. After the glitch, the file gets recorded in black and white until some other "glitch" happens and then it returns to colour. When I insert the captured file into MSP (Veditor) and scroll along to the "glitch", the program crashes with the message "VEDITOR caused an invalid page fault in module RRICMEXT.DLL at 0177:049b6d60". The captured AVI is playable and can be converted to an MPEG but, of course, the colour is all screwed up.

I am trying to record 6 x 30 minute sessions of my father being interviewed which I will then put onto CD. Because of the 2Mb limit on AVIs, I can't record at a higher quality (open to suggestions, of course) and still capture each session as one file.

My questions are:
Has anyone else had this sort of problem with colour loss in a recorded AVI?
Am I right in thinking that composite is better than Coax?
Has anyone else had similar problems with MSP crashing?
What other authoring software do people use?

Phew! A long read!
You should have seen how long it took to write (especially when I hit the ESC key on the wrong screen and wiped my first attempt)

Thanks in advance

David Stafford (DAS)
Melbourne, Australia

[gt40]

I have the same problems trying to record in 352x240 ntsc 30fps. I'm assuming this is a problem with the drivers as 5.30 is not certified to be completely compatible with the current video tools.

If anyone else has solved this problem I would appreciate your input.

[CMB]

i had probs with media studio and the scratchpad which is solved by ctrl/alt/delete then shutting down Pdesk

without this running in the background all is fine.

i dont know if that helps though,
an incidently , 5.30 is now officialy supported with video tools 1.51

[RBryant]

DAS, all these are problems with the RRICMEXT.DLL, not MSP 5.2. It is the video for windows interface driver for the RRG that comes with VT151

I have been told that this has been reproduced at Matrox and that Matrox is aware of the problem and is supposedly working on a fix.

The glitch may be caused by the Maven codec supposedly not being able to keep up with the action on the screen, and as a result it writes a corrupted frame to the avi file. Then, the crashes are caused by RRICMEXT.DLL's inability to recover from trying to render a corrupted frame back to the display.

I don't really know if I believe the line about the codec being unable to keep up with the action; I heard someone say it on another post a while back. Especially since it usually never happens in the same place twice. The only other explanation I've heard for the glitches is clock speed of the G400 with respect to heat. My Max is at default clocking and my case has 12 fans in it. Even my Xeons and my Cheetahs are barely warm to the touch.

For the time being, just try and have as absolutely little running as possible when capturing. Also, use a small, fast and effecient dedicated capture program like AVI_IO.... and use WinTop to make sure you don't have any unnecessary hidden things running that don't show up in the ctrl-atl-del box... With all this, I can usually capture 60 minutes at full screen high quality 30fps NTSC (~3MB/s) about 1 in 3 tries without a corrupted frame...

I'm still waiting for the fix too though...

[This_Idiot]

Lot's of potential reasons before the drivers take the blame. Not that they MAY not be the cause, but....

Firstly, it appears from your config that you only have one HD ? SCSI it might be, but with both the app and Windows hammering the same drive that you are trying to stream video to is not cool.

Second, I'd be getting nervous over the amount of IRQ sharing going on on IRQ11. SCSI, Soundcard AND display adaptor ?

One step at a time brothers.

[DAS]

Point taken about the IRQ sharing. As you will notice, only 9 doesn't rate a mention. Suggestions??

Ditto regarding the use of a single hard drive. The 18Gb seemed like a good idea at the time (rather than 2 x 9). Benchmark says it will do 11Mb/sec and I'm only asking for 2 or so. I guess another HD might be necessary <sigh>

I haven't altered the G400's clocking and the unit has lots of air moving to keep things cool.

Things I will try next:
capturing without pdesk running
find "AVI_IO" (anyone who can supply a link?)
capture with AVI_IO

I'll let you know how I go ... and you can tell me if you have any good ideas :-)



------------------
David Stafford
Melbourne, Australia

[Questor]

I have had the same problem, and it has been confirmed by Matrox. They say that the B&W + the GPF will be cleared up in some later drivers, but as of now, tech support recomended that I send back my RR since they can not provide a workaround or tempory solution. I have been told the bug has been duplicated inhouse. It may be true that there is a workaround with other programs like AVI_IO, but I would like to see the base package working correctly before I go spending extra cash on 3rd party programs.


Matrox G400 Drivers 5.30 w/VT 1.51

System Specs: Intel SE440BX, Pent III 450, SB Live X-Gamer 3.0, 3Com 905-TX Nic, Intel Create & Share Camera + Modem (PCI Card), Matrox G400MAX, Matrox RR, Viewsonic P817, Dual 9 Gig Seagate 7200 EIDE HD, Teac 32x EIDE CD Rom, 256MB Memory, OS Windows 98SE

[DaddyBay]

DAS,

You can find a link to AVI_IO at the Idiot's Guide. Click on the "Links" link.

[DAS]

I/O I/O
To download I must go.
[whistle] [whistle] [whistle] [whistle]
[whistle] [whistle] [whistle] [whistle]
I/O I/O

:-) Thanks

------------------
David Stafford
Melbourne, Australia

[r_cap]

Hi,
I found the same problem but as I see some of you already has some bug info from Matrox.

Hey DAS, me before with G200 PCI had also heavy problems ...caused by sharing IRQ. PCI slot 1, 5 and AGP {usually} share the same so I had to move my SB Live from slot 5 since it kicked with MGA on slot 1.
BTW I'm in mid Europe, thus also PAL. Gear was also expensive (compared to ALL other prices). The last problem I've ancountered was that you are asking for - either by time upper half of screen turns green or picture spreads to colorfull squares or just a short glitch that during mpeg transcoding causes the picture to turn non-reversibly to B&W.
What about overclocking? AGP bus may get also overclocked if you raise CPU frequency. I found my G400max to be working fine with games at 90MHz but not with PC-VCR recording - (83MHz OK).

BTW(2) Next summer I'm planning a journey to east Australian coast.

RC

[jeepman]

DAS, what is your PIII board? That may help us assist in the sharing issue.

Anyways, if you don't use your COM ports, then definitely disable them. I have my COM ports disabled and my SCSI card uses IRQ4, and my Network Card uses IRQ3. IRQ11 is used by my SBLive, IRQ10 is used by AGP. Oddly, my IRQ9 is not used either, even when I disable the ACPI in BIOS. My IDE uses IRQ14, and even though I have a CD ROM on my secondary IDE controller, IRQ15 never shows up.

------------------
ABIT BP6, 192MB PC100 RAM, dual 366 Celerons oc'd to 550MHz, 3DFXCool GlobalWin FEP32 'Lil Mofo' h/s fans. G400 DH, 3COM 905B NIC, Buslogic FlashPoint LW Ultra-Wide SCSI, SB16 ISA. Segate Medalist PRO 9.1 GB UW SCSI 7200RPM, Maxtor 20.4GB ATA66 7200RPM 2MB Cache, 8GB tape b/u, IDE 32x CDROM, SCSI 4xwrite/8xread Panasonic CD writer, 4 more various 2GB SCSI drives.

[jeff b]

Just a note to toss in here about time base correction...

Some VCR's will have an "edit mode", or something like that, or even "tbc", which will, when enabled, output the video more closely to an exact frame rate. Without that time base correction, most VCR's and camcorders can easily output non-commercial tapes at a varying frame rate, and this can cause problems with capture and subsequent audio synchronization in NLE on the computer.

One of the things that can make this an even bigger problem for NLE is that if, when capturing, the capture program is locking the frame to 29.97 or 30 (NTSC), or 25 (PAL), then the varying frame rate out of the source can never 'match' what the digitizing process needs to see. The end result can be dropped frames and weird glitches.

One way to 'test' your source signal and see what it ends up looking like to your NLE system is to capture without setting the capture program to 'lock' in the frame rate. This way, the capture will 'freewheel' along with whatever varying frame rate it's getting. After capture, you can then analyze the clip in 'properties' or go into MSP and use the 'Data Rate Analysis' utility in the 'File' menu to see what you got for a frame rate.

Remember, analogue video frame rates can slop all over the place and still look okay. Digitized video on an NLE system, on the other hand, has to be at an EXACT frame rate for everything to come out without a hitch.

It's true that other things in the system can make the captured frame rate look sloppy. All of the things mentioned in this thread so far can contribute to a captured clip demonstrating the same problems, as long as you capture without the frame rate 'locked' in. Also, the original Rainbow Runner didn't have the problem that later models seem to have in not being able to recover from a glitch or half-dropped frame, leaving the rest of the captured clip devoid of chroma (that's GOTTA be a driver bug). But the original RR did have the same problem when the whole system stole time slices with various system activities during capture, such as disk read/writes to the virtual memory, IRQ 'checks' to see if there's anything there, and even the desktop clock updating to the next minute.

The exercise that I've used in the past to clean these things up has been to use a known TBC'd source, and to capture it 'unlocked', which shows the frame rate the system is actually capturing at. When it ends up off the mark, then there's something in the system that's robbing resources during capture. But I do think that troubleshooting dropped frames should start with a known, unvarying frame rate at the source.

[DAS]

Answers to questions so far:

r_cap:
Summer's here! 30-something degrees for the last few days and more to come ... or were you meaning northern summer? I had lunch with a friend today, sitting outside at a cafe and got whiplash from trying to watch the beautiful "scenery" that always accompanies an Australian summer! ;-)

jeepman:
M/board is a Soyo SY-D6IBA2 (Dual slot 1, UW-SCSI on board). Both COM ports in use (UPS and Modem) but I might be able to free up both of those and put those devices on the server (when I configure it). Personally, I am coming to the conclusion that it is less to do with IRQs and more to do with software quality.

jeff b:
In video capture (the program) capture/video/options I have the "Exactly match the specified frame rate" always unticked. Is this what you mean? As a test, I captured 400 seconds of tape to an AVI file, which came out to about 10,000 frames (24 bit, 352x288) in MJPEG format. The properties sheet reports the frame rate at 24.999 Frames per sec. In this sample, however, there were no glitches.

As an aside, using the converter in MSP to go from AVI to MPEG1 for that file was estimated to take 95 minutes (I didn’t wait for it to finish). Using the converter that comes with the Pinnacle MP10 system takes about 27 minutes and makes a 69Mb Mpeg. A warning though: at the end it crashes with an error in rricm.dll (another Matrox dll induced error - coincidence?) and consequently doesn't give back all the resources it used.

I am now seriously considering either putting back my Hauppauge TV Card into the computer and/or investing in a Pinnacle MP10 system (using a borrowed one for testing now). Is anyone in the market for a slightly used rainbow runner?


------------------
David Stafford
Melbourne, Australia