HuffYUV Capture problems

[IvanP]

The information about Win2K idle problem I've found here:
http://search.dejanews.com/bg.xp?lev...ainboard&ST=++ (for gigabyte mb).
Problem was partialy solved to cca 7% ussage with bios upgrade but this bios release is unstable. There is also discussed a problem with FCPGA->Slot1 adapters.
Check the news for your mb.

[This message has been edited by IvanP (edited 29 June 2000).]

[kha]

It might not help you a lot nut if the bottleneck is teh disk there is a little trick taht sometimes works :
Try to put your max and min disk cache size at the same amount (256 or 512Meg should be fine)

Kha

------------------

[miker]

IvanP,
if you suspect it could be you HD speed, then you could try installing an even number of HD and striping them under NT.

This is one reason I use Win2K - I have dual 600 coppermine BTW, OT and the processors do appear 50% idle a lot of the time ... the most I've seen is a 95% peak when using LSX3 to to MPEG2 multithread. I am running SP1 release candidate, too.

Where have you read about this problem ... I obviously have a vested interest in solving it!!!

[Dr Mordrid]

Just to clarify a bit.

The lowest compression setting for PICVideo is the HIGHEST numeric quality setting: 20. This corresponds to about 5 mb/s.

Dr. Mordrid

[IvanP]

Kha:
What do you mean by "max and min disk cache size"? I added lines (suggested by Doc) to system.ini:
[vcache]
MINFILECACHE=2048
MAXFILECACHE=10240
CHUNKSIZE=1024

Do you mean the same or something else?

I can't make an experiment on WinNT because YUV2 patch for Marvels is for 9x only.
Does anybody have an experience with new Quantum Atlas V (Ultra160) HDDs real r/w datarate (connected to 2940UW)?

Ivan

[kha]

This is going to be quite difficult to explain sice I am french an have a french version of WIN98

Under Win9X right click on my computer chose properties.Then click on performances(unsure about the name but i think it is this in english) and go to virtual memory.
Click on chose my paramters (again unsure) and move the swap wether on your fatest disk wether on the disk that is going to do the capture (Generally it is the same) then chose swap file size : min 256meg Max 256meg if it is not done already.

You will have to reboot.



------------------

[Dr Mordrid]

IvanP:

He's talking about the Windows swapfile which can be set up in the System Properties/Filesystem tab. The [VCACHE] edit is totally different.

Why bother with the SCSI drives? The Maxtor ATA66 DiamondMax Plus 40's are PLENTY fast and far cheaper, even if you factor in a controller card. Even if you wanted to capture raw video (RGB or YUV) two on a Fasttrak66 would blow away a big SCSI at a fraction of the cost.

Dr. Mordrid



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

[Prospero]

Ok, a little question here. How much space is a 70 minute clip caped 704x480 going to take? I think I have a configuration problem, and I'm trying to see if my caps are set up correctly. A ten second clip is taking 165megs at this res. Is this correct? I'm also deciding if I want to buy a raid setup and am making sure it's big enough. A question for the Doc. On the Fastrack 100, what is the biggest drive array it can support under 98? I thought Fat32 was limited to 78 gig, but the promise site mentions 128gig for both 98 and 2000. Thanks for any help on this.

Note, I'm talking about capturing with HufYUV

[This message has been edited by Prospero (edited 30 June 2000).]

[Grigory]

Ivan,

I have tried this codec with very similar capture card: Canopus DV Raptor + analog capture kit. This videocapture device can do in YUVU (can't remember exactly the combination, but it is mentioned as having only different byte order from YUY2) with frame size 360x288 or full 720x576.
The format is supported by huffyuv codec natively. RGB works worse.
I have dual 510 celerons, but can use only one of them under 98. I suppose the codec works on single CPU, so there is not so much difference.
Also, the codec does not use SIMD instructions (floating point), so there is no difference what CPU to use.

What I have found with analog output of D8 camcorder :
1. Full size cannot be compressed for my typical video content. Sometimes I see reasonable CPU load, but then it goes up to 100% and here dropped frames occur. The data rate (turn ON Disk: bytes written/sec in system monitor) varies from 6 to 12 MB/sec, and probably might go higher, but limited by CPU overloading and dropped frames.
2. Quarter size worked well and allowed to see how the CPU is loaded actually. Well, it is typically 22-24%. Assuming only linear dependence from the frame area, this gives up to 96% of CPu load, but add here at least 10% for disk writes, and 10-15% safety margin. The worst is that sometimes the CPU load goes over 30%, and the data rate may become up to 5 MB/sec.
3. All these values are varying. Some clips are well compressible, but another (and not the same that give the highest datarate with MJPEG!) may produce very high data rate values. The compression scheme is very different from MJPEG, so you may get low datarate from clips with sharp details and high datarate from smoothed color changes, just in the opposite to MJPEG.

4. Forget about system cache optimizations. For the best sequential write speed, you must disable write-back cache at all. All other settings actually cannot help, or make your drive working slower.
5. Forget about "low" PCI speed. It is the same for all "regular" setups = 33 MHZ. It is more than enough to serve both video capture and preview. For example, you easily can preview full size live video with Marvel or any other TV tuner card, and simultaneously capture video. More, overlay mode of preview actually frees a lot of CPU power, but not limits the ability to view and compress data. Overlay preview (doubled data flow over PCI bus) or no preview actually give you the same capture performance.

Another observation - it is possible to play full screen 720x576x50 HZ (full 50 frames per second) with G200 and G400. I made such movies and they were not limited by the PCI bus. I even could play original Canopus DV at doubled speed, after editing the frame rate code in the movie.

Surprisingly, I found that S-video connection provides slightly lower data rate and CPU load with huffyuv codec than composite connection.
Possible explanation is that S-video signal is free from addtional intermodulation between luma and chroma components. The difference was sometimes up to 10%.

Conclusion:
At least for my typical movie content, I cannot use 510 MHZ Celeron reliably with huffyuv codec at full size.


Possible solution:
buy cheap BT8x8 card, run VirtualDub, set slightly less frame width and capture. Set say 512 pixels frame width and save some space and CPU cycles. Typically, you should be unable to see the difference in horizontal resolution on TV.
My own experience shows that the quality of video digitization is about the same for all capture cards.
BT cards are cheap, and they can work only in uncompressed mode, but they support a lot of formats and work reliably with them.

For example, you might find useful 4:1:1 format, which is actually what you get from analog output of DV camcoder: if you compare luma and chroma resolutions of this signal, you can see 1:4 or 1:5 ratio, which is normal for analog video.
What is the reason to capture extra 4 bit per pixel? I suppose that such "compression" may be better than huffyuv, because of predictability. Another format is YUV12 - 4:2:0 - exaclty what you have inside your camcorder.
Note: I am not selling or even using BT cards now. This information is based on my positive experience with them before I went to DV through RR_G.
I still think non-compressing cards are underestimated, especially now, when we got really fast hard drives.

Grigory

[kha]

Concerning ATA 66 it is a norm I do not like at all for the moment.
In the future it might prove fantastic but for now it is quite inutile. In fact it is exactly the same problem as AGP 4x, beatifull in theory, useless in the facts.
The problem of ATA66 is double :
First you won't get close to the 66m/s in fact your perf will be those of a standard ATA33 disk.
See Anandtech for the benchs. http://www.anandtech.com/showdoc.html?i=1237

The second problem is the amount of cpu time taken. On my maxtor diamond+ 10,2Go my pro some times goes as high as 32% cpu taken for copy from disk to disk. (I have an Athlon 500 not overclocked).

On the other hand my IBM 4,3Go 7200T never take more than 8% and my brand new ATLAS 10K
160M/s (in theory for I have not the controller that fits) 12%.....

IMHO you can not compare scsi U2W and ATA66.

By the way the answer to IvanP is the following : If you plan to capture using only Hardware codecs (which for personal reason I do not like) and if when you capture your pro never goes higher then 66% then you do not need such a big drive.

On the other if your want ot try other codecs and/or want to apply filter on the fly you will definitly appreciate the power of scsi.

Kha

[IvanP]

Hi,

After a few holiday weeks I'd like to thank you all for your last responses. A
lot of news and surprices has been comming in the last three weeks. New panasonic
and HuffYUV, a lot of interesting topics... I'm looking forward to a new tests.

Ivan

[This message has been edited by IvanP (edited 26 July 2000).]