would huffyuv drop more frames than uncompressed while recording?

[nukesgoboom]

would huffyuv drop more frames than uncompressed while recording?

i was wondering, is it better to have a fast, lightweight lossless codec like huffyuv to reduce the data dumped to disk by about 30% or is it better to have just uncompressed data being dumped with no intervention?

i am using a program called dscaler with 640x480 30 fps capture settings, source is an xbox 1 with s-video input. the capture device is a card installed into a pci slot on the motherboard.

computer specs:
3.2 ghz p4 prescott revision e
1 gb corsair ddr ram
10,000 rpm sata harddrive

which method would conceptually drop less frames? (less work for computer?)


thanks for your time.

[Shinigami-Sama]

I'd have to say using huff would yeild better results just based on the fact disk drives are slow, and huff is a very lightweight codec and doesn't use much resources; and because of the drop in data to be writen is droped theres less chance of the drive not being able to keep up with the data transfer rate

[nukesgoboom]

ah so huffyuv would reduce the chance of the disk not being able to keep up.

true, but what about the resources spent on huffyuv? could they be applied to the uncompressed format and yield the same? isnt it just less work for the computer to dump uncompressed frames, therefore reducing chances of lost frames?

: )

[foxyshadis]

Is it so hard to turn on the xbox (the cd viz if you're feeling fancy), capture in each mode for five minutes, and check on which has more dropped frames?

Anyway, the only "resource" being applied to uncompressed video is memory copy and disk speed. Having a raptor helps, but you obviously can't apply spare cpu to extra disk speed, so using 10% of the cpu instead of 2% to tremendously reduce the chace of drop seems like a worthy tradeoff.

With that cpu your question would apply more to lagarith, ffv1, or some of the other much more cpu heavy lossless methods.

[nukesgoboom]

i have tested in both modes and they both seem to work great, however recently one of my huffyuv captures dropped a few frames which caused me concern.

your telling me its better to capture to huffyuv and not uncompressed, because the 30% reduced data flushed to disk is better than sacrificing the cpu power to encode it?

thanks for your time. just hoping for a solution.

[Shinigami-Sama]

if you have the cpu power why not use it?
the only thing I could think of as to why it droped a few frames is that there was a sudden cpu spike
a timed application used CPU resources
or maybe a disk analyiser hogged the drive

or to make sure you never drop frames again
raid-0 overtop of raid-0 and multi-core system with only [insert codec here] using the the number of desired cores or what have you

[foxyshadis]

When capturing you absolutely have to make sure that anything that can interrupt the steady flow is shut down. Virus scanners off. Defragmenters off. No web browsing or music, unless they use a different physical disk. No movies at all. Make sure the capture is set to above normal priority or high (vdub should default there). Keep in mind that a ot of media software will try to rebuild their libraries every half hour to hour.

If the situation with huffyuv repeats, and it's not because of process priority, it'd definitely be best to switch back to uncompressed (but try for uncompressed YUV (like YUY2), since that's what raw analog signals are).

[nukesgoboom]

absolutely everything is off. of course i know that! all programs shut down except for dscaler which is recording. all useless microsofts services/ non microsoft services are unchecked in msconfig, and all startup options are unchecked. NOTHING is running but dscaler.

i dont have virus scanners installed. i just use AVG free from time to time, which is NOT enabled to be on. i actually have the AVG service disabled from services.msc

the uncompressed format used is YUY2

i do not use a raid drive, just a single 10k rpm 80 gig SATA raptor.

im also using about half of my harddrive, in case that matters. 40/40 gb used.

[Shinigami-Sama]

maybe you hit a chunk of fragmentation that the disk couldn't buffer enough for?

[foxyshadis]

Awesome, in that case you should never have dropped frames with either method, although vdub 1.16.x is a little better than dscaler about dropping frames. A little better buffer management I suppose.

[nukesgoboom]

GOOD IDEA... i better defrag before my next capture. i do a defrag once a month anyway but who knows? thanks for the idea.

i use O&O defrag 8.5 pro, and i choose the NAME defrag option. you guys use similar options?

i have some thoughts on virtual dub capture. it works for me but the video is SUPER SUPER DARK! like you cant even see half the stuff going on!! other than that, it works, but it SO DARK..i tried a brightness filter but it does not help : ( thats why i use dscaler. its the best quality i have seen for a recording.

honestly, i believe dscaler to offer higher quality recording than virtual dub. that is just my experience and i have to mention it. how do others feel about dscaler vs. virtual dub capture?


here is an example of what im talking about. i recorded this with huffyuv and then encoded to xvid... do you see any dropped frames in here:

http://www.fileupyours.com/files/48999/frost38.avi

[unmei]

i use dscaler as well.
For me it is the only program i have come across that at the same time captures reliably and also is a nice to use app for TV-watching.
Also i totally love how it adapts its deinterlacing method. Usually it gives me a very nice picture but if CPU becomes scarce it will rather fall back to a cheap deinterlacer than drop frames. One thin to note tho, in its setup i set it to give priority to other apps, not the only app on the computer but priority to dscaler and tell it i have a 300-500mhz cpu even tho it runs on a XP 2600+ (2GHz) this is the way i found it to adapt best.
PS for capturing i use XviD, yes this is *not lossless*, but Q2-3 with no motion estimation or any frills is very fast, doesn't cause my HDD to choke and considered the noise in the captured signal i have never found compression quality to be a problem. The stuff i actually decide to keep i later postprocess offline with slow avisynth denoising and encode with x264.

[Revgen]

I like Dscaler too. Unfortunatley, I still can't cap with FFDShow with the newer versions and DOS (the Dscaler record programmer) hasn't fixed it yet. It would be great to cap using FFDshow's codecs.

[nukesgoboom]

why would you want to record into ffdshow's codecs? why not just use huffyuv for a lossless approach, so you can edit it later?

im taking it you guys never drop any frames, ever, lol. i have never tested capturing to a lossy format before, it must be hell on the cpu, i mean it has to have at least a 30 fps rendering rate or you will drop frames!

[AVIL]

Hi,

In my case (fast HDD ATA133, and slow CPU Via's Nehemia), I can capture video uncompressed without dropped frames. With huffyuv, I get dropped frames. I capture with VirtualVCR. Periodically, I do housekeeping on the harddisk (erasing unused files, defragmentation, ...). Also I have rised PCI latency of video card up to 192.

[nukesgoboom]

what resolution and FPS are you recording at?

[unmei]

nukesgoboom, no it isn't hell.
I capture at 720x576 @ 25fps (PAL-land) YUY2 (well it's converted to YV12 in xvid of course..)

I mentioned my CPU already, its "pretty old" and cheap components when compared to what some people here use, althon XP 2600, single channel board (A7N8X-X), 1GB non-name RAM, nvidia 5700, no overclocking anywhere. The HDD is also rather old PATA133, the partition i capture to is only used for pagefile and video captures, the other partition on that drive has data and programs, but windows itself is on another HDD on the other controller. According to nero, the hdd makes about 28MB/s for reading (the in this case important writing it doesn't tell :|)

As for xvid, no it is not that slow:
huffyuv 2.1.1 uses between 30 and 70% CPU (avg maybe 45, but has huge peaks) while XviD uses quite constantly ~70% CPU with of course everything off that is only used to improve coding efficiency, that means: no b-frames, no qpel, no gmc, no chroma optimizer, MSP 0, VHQ mode 0, no chroma motion, no trellis.

ps:
i installed the latest nvidia driver yesterday and have the feeling it made my capturing slower - i used the original drivers up to now, never updated, and from memory i would have said xvid used to use about 60%, not 70% - but maybe that is just a bad feeling i have about that driver :).

[nukesgoboom]

i hear you on those nvidia drivers. up until 2 months ago, i was using drivers for my nvidia geforce 4 ti 4800 that were almost 3 years old, they came out during the counterstrike 1.5 days.

it seems the best solution is to record to uncompressed if you can spare the disk space. if you cant spare the space, use huffyuv.

if you record to xvid, your going to have to re-encode over a lossy format to edit the video, which is a great way to lose quality : ( i always have to edit my captures so i dont do this. huffyuv is just fine i you need to save the space.


ultimately, use uncompressed if you are recording something small like 5-10 minutes. any longer than that, use huffyuv.

a trick i use it to minimize dscaler so it isnt on the screen showing me a preview. this way, it takes 1 less MB in the ram, and hiding the preview may help with the recording process. all my captures have come out fine with this trick. thoughts?

[unmei]

i hear you on those nvidia drivers. up until 2 months ago, i was using drivers for my nvidia geforce 4 ti 4800 that were almost 3 years old, they came out during the counterstrike 1.5 days.
I reverted to the old driver of 2004. The results i gave above are not accurate in that i was unable to have reliable recording, even with only 384x576 or 720x288 in the long run. Back with the old drivers i actually have the 40-60% CPU use for full frames again i though i always had before. I have *no* idea how they can cock-up so hard, the drivers kicks back the recording process to less than half the performance.

if you record to xvid, your going to have to re-encode over a lossy format to edit the video, which is a great way to lose quality : (
I'm aware of this.
The quality loss in a 25mbit/s (Q2) xvid is negligible to the quality loss due to noise and the final lower-bitrate h.264 encoding (i aim for 400-1500kbit/s there, depending on content characterstics and "importance" of the capture to me).
ultimately, use uncompressed if you are recording something small like 5-10 minutes. any longer than that, use huffyuv.
Usually i do not plan specific recording sessions. Usually i watch TV and then i decide i want to record - Shift+R - go. Even when i plan in advance to record i'm too lazy to go into the settings everytime. For me it would be switching huffyuv<->xvid anyway, i don't have the space to record anything over a few seconds in huffyuv and usually i don't want to process the capture immediately after.
a trick i use it to minimize dscaler so it isnt on the screen showing me a preview. this way, it takes 1 less MB in the ram, and hiding the preview may help with the recording process. all my captures have come out fine with this trick. thoughts?
I don't think this has much influence.
If it is just the tiny bit that keeps you away from dropping frames it's nice of course. For me, i have no problem, now that i returned to the old driver:) (also i usually like to watch while capturing).

[nukesgoboom]

i firmly believe these new drivers only contain updates for the newer nvidia cards, which is a shame because you are FORCED to download a SINGLE package of drivers for ANY nvidia card. this is cool in concept but how can you have a single driver running at least 7 different cards??

what exact version do you have? im on 91.31

i should try that xvid q2 capture format sometime, just to see how fast it goes, now that you say the loss is negligble. should be interesting.

nice work on using x264, im still too much of a noob to use MEgui, and i know there is a vFW x264 codec that works with virtual dub, but im told x264 is not fully compatible with the .avi container, but when i encode with it, the resulting .avi files always work well enough.

i wonder why its listed as not compatible? just to stop people from retarding the technology?

[unmei]

This driver does not yet seem to go after that same numbering...

When i go to device manager->display adapter it says driver date 2004-07-15, driver version 6.1.7.7 and the version of individial driver DLLs as reported by the NVidia control panel is mostly 6.14.10.6177 (so maybe that means 61.77 in the new numbering ;)) with a few misc DLL's version 6.14.10.11048 - i guess these could be left overs from the install of the new driver in case the old one didn't have them yet.

The new one that was so much slower was labeled 91.47.

i don't use megui, i use the CLI "directly", that is i wrote a few batch files for my usual scenarios (one for crf, one for faster crf, one for twopass) so i don't have to type a dozen parameters each time. This creates either a mp4 or a mkv, mkv for me because i add vorbis audio and -for dvd backup, not for TV caps- soft subtitles. Actually that is the same as using megui, just without the GUI :)

Yes the resulting avi works, but the x264 encoder has to make some compromises for output into avi. The topic is pretty much a holy war and much discussed in the AVC subforum, so i won't say more.

[nukesgoboom]

i just went to C:\nvidia\win2kxp which had a folder in there called 91.31 and i know thats the name of the drivers because i remember that number.
i get the same number when i go to device manager and look at the driver name for the video display adapter.

you use 'CLI' directly.. jesus H christ thats some huge technical know-how, i dont know squat about writing batch files either. very impressive your far beyond my level ill give you that : )

thanks for the info about the x264 encoder making compromises. i didnt know that. i know .mp4 should be used, because its just retarding the technology as someone said somewhere else.

im just another guy waiting patitently for a virtualdub clone to come out and support .mp4. then you will see an explosive gain in use of the .mp4 container. i bet you .mp4 will hit mainstream like xvid .avi is right now, as soon as a VD clone with .mp4 support is released.

hot damn x264 looks SOOOO GOOD!! i heard the guys behind the VLC player had some hand in making x264 is that true??

[foxyshadis]

I'd pick up avidemux if you're looking for a mp4 vdub. It's quite a bit less polished than virtualdub, but it's very functional and can do quite a bit with mp4 (as well as mpeg avis).

[nukesgoboom]

sure! ill be googling avidemux right now.

strange name though, why include avi in the name if its main goal is mp4? cant wait to try it. does it support filters made for vdub though? i use an awesome deinterlace filter thats made for virtual dub called area blend. hope it works with avidemux lol

[Shinigami-Sama]

why avi in the name?
read the second half
'demux'
meaning you're getting it out of the avi ;)
hope you can figure it out mate