HuffYUV Capture problems

[IvanP]

Hi,

First important hw&sw environment:
Marvel G200, dual PIII450, 256RAM, capture disk Seagate Barracuda 7200rot/min UW SCSI (empty). Matrox PD 5.52, VT 1.52, FlyDutch YUV patch, avi_io 2.39, huffyuv 1.3.1, VirtualDub 1.3c build 10805. Doc's recomended changes to system.ini of Win98SE.

Problems:
Avi_io:

When I capture @ 704x576 25Hz PAL, used I/O buffers showly increasing while reaching 50 limit and capture stops after cca 2-3mins. No drop frames.

VirtualDub:
cca 10% lost frames. Doesn't matter if I'm using internal or VidCap capture method.

Resulting avis are cca 7500kbps and that is below benchmark of that drive.

Note:
Half size 352x576 @ 25 is no problem in avi_io, VirtualDub not tested with that resolution.

Thanks in advance,

Ivan

[Dr Mordrid]

Your processor is likely too slow. I'm using a PIII600 and it's just barely enough for full frame using HuffYUV. HuffYUV is efficient but still needs some processing horsepower.

You also might want to go to the AVI_IO capture setup page and select the "force key flag" option. This is important for the Marvel/RR-g. Most likely for the RRS too but I haven't tried it yet.

Dr. Mordrid

[Flying dutchman]

Doc, the keyframe flag option is only needed for raw yuy2 capture, not for HuffYuv.

I can capture full-resolution (704x576x25 PAL) using avi_io and HuffYuv. The "buffers" counter occasionally gets as high as 30, but on the "quieter" scenes it drops again. And I only have a Celeron 466! My hard disk is fast, though (Maxtor 40 gb)

[IvanP]

Yes I thought that problem should be in CPU power because in VirtualDub it often displays 100% CPU ussage sometime 70-80%.
Now I'm confused when Flying Dutchman can capture full PAL resolution on Celeron 466. Maybe HuffYUV needs only slightly more MHz and not other features of full PIII.
My test video is VHS live Metallica S&M, there is also fast movement, lights quickly changing... you can imagine. There is no measure for "quieter" or "faster" scenes. Yes sometimes it oscilates around 8-10 used buffers but when it start to increase slowly it never stops and after cca 2mins it reaches maximum.

I forgot : Sound card is SB Live! Value. Also I haven't upgraded my Marvel's bios. I'm using factory one. Is it necessary to upgrade?

Ivan

[Dr Mordrid]

The difference between you guys and myself is that you are capturing PAL at 25 fps and I'm capturing NTSC at 29.970 fps.

Even considering the larger frame size of PAL I still have to push the equivalent of 4 more frames/sec worth of data though the pipe, a 16% difference.

Dr. Mordrid


[This message has been edited by Dr Mordrid (edited 21 June 2000).]

[mgu2]

NTSC: 704*480*30 = 10137600 bytes
PAL: 704*576*25 = 10137600 bytes

The datarate is exactly the same, no 16% difference.

IvanP, try to capture a no-change scene (paused VCR or something). Then you can be sure if it is a too-complex-scene problem or not.

[mgu2]

Small mistake. The datarate should be, of course, multiplied by two or three (RGB).

[IvanP]

Thank you all for your suggestions. I'll try to capture 'quiet' video and also my friend (dual PIII650) will try if the problem is CPU speed. Unfortunatelly he has got AVMaster and I don't know if it supports YUV2.

To Flying Dutchman:
Why your YUV2 patch is not available for NT4?

Ivan

[Dr Mordrid]

mgu2;

I wasn't referring to the data rate in bytes, but the frame rate in frames/sec. NTSC does have to push more frames/sec through the pipe regardless of their byte size. More frames=more overhead.

Dr. Mordrid


[This message has been edited by Dr Mordrid (edited 23 June 2000).]

[Walrus]

Dr Mordid: I guess it really depends on the codec in use (some codecs could work better with many small frames instead of few large frames), but my understanding of HuffYUV would seem to indicate tha more frames = worse performance.
For what it's worth, I have a dual Celeron 366 overclocked to 550, and under Win98 (with only one chip active) I can capture HuffYUV in full res NTSC with ~ 1 frame lost/1000 with VirtualDub. If I clock the chips to ~ 510 mhz (which I normally do for heat issues) the drop rate is completely unchanged.

[mikiem]

Walrus,

Please pardon an Off Topic comment - trying to be helpfull... Running a celeron 333 I found Oda's sfsb useful in a similar situation -- o/clocked the m/board, then set sfsb to start with windows reducing the clock speed (didn't need the extra heat when on-line etc.). A quick click on the taskbar & I was back to full speed.

Back to the thread, I have to weigh in on the side of drive transfer setup & speed determining capture rate. The marvel g400 setup doesn't seem to like my adaptec 2940UW SCSI card, preferring IDE. On the other hand, playback much favors the faster streaming av drive... what a pain!

thanks
mikie

[Dr Mordrid]

Processor speed does affect PCI throughput and a C333 is near the bottom of the Marvels specs (min=300mhz). Adding another PCI device may be just a bit too much for it to handle.

Dr. Mordrid

[Walrus]

mikiem:
I've heard about it before, but as I always have a distributed.net RC5 agent running, I never have downtime.

[IvanP]

I've upgraded my system to dual PIII550. It is maximum that my board Gigabyte GA-6BXD supports. (It supports 600(katmai) too but it's out of stores and ordered are very expensive. Coppermines has a problem with Win2k (50% idle of one proc.).)

What I've found:
Avi_io:
Still the same problem. It ocsilates using 2-5 buffers. When it slowly reaches 10-20 it starts to increase more quickly up to 50 in 30secs. Total capture time is 3mins maximum.
VirtualDub:
With an exception when capture starts with few dropped frames it captures without any problem. CPU ussage oscitates from 40-80%.

I've found that the problem can be HDD too.
When I tested my SCSI UW Barracuda 7200rot with EZSCSI benchmark it has reported 9Mb+. But I was surpriced with the results from Matrox HD benchmark which is 6.4MB only.
Full size capture requires cca 7.5MB

Can anybody tell me where the problem is?
HDD is connected to Adaptec 2940UW PCI to SCSI board.

thanks

Ivan

P.S.Sorry for my English.

[Walrus]

IvanP: I get the feeling that your bottleneck *IS* your hard drive. Keep in mind that the AVERAGE data rate for full res HuffYUV is ~ 8 mb/sec. That doesn't mean that it doesn't often spike at MUCH higher data rates for periods of time. Also keep in mind that datarates differ quite a lot in different areas of the disk. The inner parts of the platter spin a lot faster than the outer portions, and thus the start of freespace is faster than the end. If your benchmarks are reporting speeds that are either barely above or just below 8 MB/sec, you probably are too low. My hard drives rate at least 12MB/sec, and they all capture Full Res HuffYUV in VirtualDub without a problem (~ 1 frame lost /1000)
You may want to try capturing using PicVideo's MJPEG codec with the lowest setting for compression which should be nearly as good as uncompressed HuffYUV with a slightly lower datarate.