Capture codec for low CPU useage

[BlackSharkfr]

Hello,
I doing some very special recordings using my TV capture card.

I play games in stereoscopic 3D and want to record some footage, usual computer recording softwares do not work (fraps, gamecam, etc...),
So i have to use my TV capture card and record my to-output as interlaced (field sequencial stereoscopic-3D)

It works but it requires the game to run at a perfectly steady framerate.
I managed to record a few old games, but since i play and record on the same PC, i can't record more recent games since the CPU useage is too high.

My capture card is a cheap Hauppauge win TV express PCI card.
Until now, i used DScaler with Lagarith codec, but even at a very low capture resolution (i went as low as 480x480), the cpu useage is still too high.

I am now looking for other codecs (either lossless or lossy codecs) that require less ressources for live capture, and are able to keep the interlacing.

I hope you can help me, thanks.

[manolito]

I remember reading about MJPEG codec comparsions in the German Doom9 forum, and the PICVideo MJPEG codec consistently had the lowest CPU useage. I do not remember if they tested version 2 or 3 though.

Cheers
manolito

[easy2Bcheesy]

Surely Huffyuv is the obvious choice? It's definitely more light on the CPU than Lagarith.

[LoRd_MuldeR]

Maybe even x264 in lossless mode can be used. Using fast settings, I can get it to encode at ~60 fps for SD content (720x576) easily :)

[Dark Shikari]

Maybe even x264 in lossless mode can be used. Using fast settings, I can get it to encode at ~60 fps for SD content (720x576).HuffYUV is surely quite a bit faster than x264, even on subme0/1 + no cabac + no scenecut + no partitions.

[LoRd_MuldeR]

HuffYUV is surely quite a bit faster than x264, even on subme0/1 + no cabac + no scenecut + no partitions.

But if you find the slowest x264 settings that are still fast enough for realtime capture, it will certainly give a smaller file than HuffYUV.

Even with the 60 fps settings the file was smaller than HuffYUV (715 MB -vs- 830 MB). And I could have used slower settings for realtime capture.

If speed (CPU usage) is really the only thing that matters, then HuffYUV is the winner though...

[BlackSharkfr]

My aim is realtime capture + as much room as possible for the game. (game + capture on the same PC with performance requirement on both)

Will try again with huffyuv, in case it is not enough, what lossy codec may i try ? i've seen FFdshow's MJPG but for some reason FFDshow doesn't like DScaler, i get very bad quality image if i use ffdshow, whatever the codec used, i don't know why.

[LoRd_MuldeR]

I doubt there is any encoder that is much faster than HuffYUV, except uncompressed :D
But with uncompressed video your HDD will quickly become the bottleneck!

You could try x264 with absolute fastest settings. Try Subme=0, disable CABAC, uncheck all partitions and select "diamond" search.
It can be REALLY fast then. If you can live with lossy compression, try CQP mode with CQP > 0 (e.g. CQP = 22).

Also MPEG-1 may be worth a try, speed-wise at least...

And please define "bad quality" for ffdshow. The ffdshow VfW part should work just like any other VfW encoder.

[squid_80]

Using HuffYUV will result in a file that's much more edit-friendly than using x264.

[LoRd_MuldeR]

Using HuffYUV will result in a file that's much more edit-friendly than using x264.

Yes. But thanks to DGAVCSource() editing H.264 isn't a big problem either. At least for Avisynth-enabed tools.

If uses a VfW encoder, which I think he does (DScaler), he'd need to extract the H.264 stream from the AVI container first though.

[BlackSharkfr]

i have used ffdsow encoder many times in many different applications and it always worked well but for some reason i can't understand, when using Dscaler, the end video is screwed up,
The video still works but the resolution looks fake, there are some weird artifacts that look like interlacing (but aren't). In the end the video looks really bad, whatever the settings i choose inside ffdshow.
I have also had the same bug with other codecs in DScaler so i assume it's a DScaler issue and not an FFDShow issue.
It's just that lagarith works so i haven't used any other codecs so far.
Will try a new recording this evening.

[mgh]

try using virtualdub or virtual vcr instead. dscaler is designed for watching tv, not so much for capture.

[LoRd_MuldeR]

1. It may help to post a sample of the "screwed up" video.

2. Instead of Lagarith, you should give HuffYUV a try (either from ffdshow or the standalone version). HuffYUV significant faster than Lagarith!

I'd only prefer Lagarith over HuffYUV, if I need better compression and can handle slower encoding.

[johnsonlam]

Surely Huffyuv is the obvious choice? It's definitely more light on the CPU than Lagarith.

Before I changed to AMD Phenom, Lagarith have a few drop frames on my AMD Athlon64, I believe HuffYUV still is the best choice for capture, especially the new patch version from Squid_80 (Thanks!).

Also surprisingly I found MediaPlayer Classic (old version, never tried the new one) have a very smooth capture ability, it help a lot when I need to convert my VHS and process with VirtualDub, my Canopus card didn't like other programs except the WinDVD creator but it lack lossless capture ability.

[2Bdecided]

Near-lossless edit codecs (e.g. Canopus HQ, Cineform) seem to be faster that HuffYUV, because they require far less disc access. That's my experience on my (slow!) machines anyway. YMMV.

Cheers,
David.

[LoRd_MuldeR]

Another point for maybe going the "x264 lossless with fast settings" way:
http://forum.doom9.org/showthread.php?t=143540

[squid_80]

Another point for maybe going the "x264 lossless with fast settings" way:
http://forum.doom9.org/showthread.php?t=143540
OP wants to keep the interlacing intact though. x264 may support lossless but it's limited to YV12 so the interlacing will be b0rked, unless I'm missing something.

[LoRd_MuldeR]

x264 may support lossless but it's limited to YV12 so the interlacing will be b0rked, unless I'm missing something.

I think x264 has a working interlaced mode, although it's not as optimized as it could be.

Also converting interlaced video from RGB to YUV should be possible, if done correctly. Right?

[squid_80]

Whether x264's interlaced mode is optimized or not won't matter in lossless mode, since it's lossless :D But even if the YV12 conversion handles interlacing properly it will still halve the chroma resolution vertically, and I'm not sure what effect that will have on "field sequential stereoscopic-3D" images.

[LoRd_MuldeR]

But even if the YV12 conversion handles interlacing properly it will still halve the chroma resolution vertically, and I'm not sure what effect that will have on "field sequential stereoscopic-3D" images.

Okay. But the same would happen with any encoder that doesn't accept RGB32, no matter if lossy or lossless.

A proper HuffYUV version with RGB support would be fine. x264 won't be, as long as there's no full 4:4:4 support.

Not so sure about all the others mentioned...

[squid_80]

No, YV12 sucks compared to RGB or YUY2 because it has vertical chroma subsampling which might end up blending the fields. YUY2 would preserve the interlacing and it's closer to the original analog signal than RGB.

[BlackSharkfr]

Doesn't interlacing encoding completely separates the fields and encode them into different (virtual) frames ?

[LoRd_MuldeR]

The problem with some YUV formats is the chroma subsampling. The subsampling happens when converting from RGB to the YUV format, so before the actual encoding.
Subsampling may blend the (color) information of neighboring lines together, lines that belong to different fields and hence shouldn't be mixed together!

See this for more info:
http://en.wikipedia.org/wiki/Chroma_subsampling#Sampling_systems_and_ratios

(I think 4:1:1, 4:2:2 or 4:4:4 would be okay for interlaced, but 4:2:0 wouldn't. Guess that's the YV12 -vs- YUY2 difference mentioned by squid_80)

[2Bdecided]

YV12 interlaced still keeps the lines from separate fields separate - the "bluring" is within field, not across two fields. That's why YV12 interlaced sampling is defined as subtly different from YV12 progressive sampling.

If it wasn't so, then any movement on a standard interlaced source (never mind this 3D one) would have horrible chroma ghost trails. You sometimes see this when people handle YV12 incorrectly.


All that said, I wouldn't used YV12 in this instance.

Cheers,
David.

[squid_80]

The "Assume interlaced if height >" option on ffdshow's input page would probably enable a proper interlaced conversion but I'm not sure.

[BlackSharkfr]

ok i've done some new trys and it works much better.
This time i followed your recommandations
virtualdub capture + huffyuv and it is much much faster and allows me to play newer games and capture in real time.

I also found a way to display the "broken" image by forcing virtualbud to use a wrong input colourspace and then the preview just looked like the broken image i used to have.

I also noticed that with newer versions of ffdshow the broken image doesn't happen anymore with both Virtualdub and Dscaler, so i suppose it was a colourspace detection issue with older versions of ffdshow i used to have last time i tried to use ffdshow encoder in Dscaler.

[LoRd_MuldeR]

YV12 interlaced still keeps the lines from separate fields separate - the "bluring" is within field, not across two fields. That's why YV12 interlaced sampling is defined as subtly different from YV12 progressive sampling.

If it wasn't so, then any movement on a standard interlaced source (never mind this 3D one) would have horrible chroma ghost trails. You sometimes see this when people handle YV12 incorrectly.

Well, it seems there is a way to convert interlaced material to YV12 properly. But that isn't automatic! It requires a "special" method.

From Wiki:
With interlaced material, 4:2:0 chroma subsampling can result in motion artifacts if it is implemented the same way as for progressive material. The luma samples are derived from separate time intervals while the chroma samples would be derived from both time intervals. It is this difference that can result in motion artifacts. The MPEG-2 standard allows for an alternate interlaced sampling scheme where 4:2:0 is applied to each field (not both fields at once). This solves the problem of motion artifacts, reduces the vertical chroma resolution by half, and can introduce comb-like artifacts in the image.

[squid_80]

Well, it seems there is a way to convert interlaced material to YV12 properly. But that isn't automatic! It requires a "special" method.That's what I've been trying to say :D With VFW there's no method to indicate interlaced YV12.

[2Bdecided]

Well, conversely, there's no way to indicate progressive YV12 either! I'm not sure pixel aspect ratio gets communicated either. Neither does whether the actual content is progressive or interlaced. These are things you just have to "know".


It's not that it's "special" - it's just that you have to know what you're doing.

(I'm not saying it should be used in this context - just that interlaced YV12 is no more or less standard than progressive YV12 - or even interlacing itself!)

Cheers,
David.

[LoRd_MuldeR]

Back to topic:

I have not tested it yet, but this looks like another options and an alternative to HuffYUV:
http://forum.doom9.org/showthread.php?t=143624