Need to encode 720p from webcamera on the fly

[Huddler]

Hey guys,

I want to record my webcam stream (RGB24) into a file on the fly.
Its very important that this happens with the lowest possible CPU usage while not being bigger than about 4 GB per hour and a codec that has a video compressor DirectShow filter, like ffdshow.
Maybe there is even a Quick Sync Video encoder (I use a Sandy Bridge)? That way I could even use 1080p, which would be awesome.

Right now I am using x264vfw on an ultrafast preset with 4750 kbps. Single pass.

This works ok (about 3.5 to 4 GB per hour), but I wonder if there is a better way with a codec that supports multicore CPUs and produces smaller files at better quality and hopefully a different container than avi.
Any suggestions are appreciated. I am still quite a newbie at encoding.

Any opinions on TMPGEnc or this one?
http://www.norpix.com/products/codecs/directshowcodec.php#

Thanks in advance!

[Huddler]

Nobody wants to help me? :(

[diogen]

Real-time encoding isn't very high on the requirements list of free encoding tools and/or consumer equipment.

Hauppauge (http://www.hauppauge.com/site/products/data_hdpvr.html) is probably the only consumer box doing this.
But it needs component in and most likely can't handle RGB24.

Diogen.

[Dark Shikari]

This works ok (about 3.5 to 4 GB per hour), but I wonder if there is a better way with a codec that supports multicore CPUsx264 has supported multithreading since 2005.

and produces smaller files at better qualityNothing will beat x264's compression/speed ratio, most likely, but ultrafast is completely pointless. On a decent CPU ultrafast is going to be quite literally 10 times faster than you actually need. Use a better preset.

and hopefully a different container than avi.Stop using Virtualdub? The container muxed to has nothing to do with the encoder you're using.

[sneaker_ger]

I don't know if it works for live recordings, but there are ways to not let VirtualDub write the x264 output into avi:
1. some x264vfw versions offer their own file writers, so VirtualDub will only create a dummy avi file
2. VirtualDub 1.10.0 and newer have support for external cli encoders.

[Blue_MiSfit]

There are indeed x264 builds for vfw that have their own output modules. They're actually pretty well done, if you ask me.

If you use this method, Virtualdub or whatever VFW application you use only writes a placeholder AVI. The actual output file path and type is specified in the x264 encoder configuration.

I've used this method before, and it works pretty well. You are using VirtualDub to do the RGB -> YV12 conversion right? I'm assuming YV12 is adequate for your purposes.

Derek

[Huddler]

Im using a camera plugin, very similar to MiniCam. I dont use VirtualDub.

Ultrafast does help quite a bit. I tested a whole day long to see whats using the least CPU power. On ultrafast CPU usage is about 5% lower than on veryfast.
It still runs very close to the limit, so its still too much, since I cant activate overlay (GPS info, date, time, etc) without noticeable slowdowns.

So you guys think x264vfw is already the best way?
Is there none with QVS or that makes use of the integrated h264 hardware encoder of the Sandy Bridge CPUs?

Any idea how I can choose the container in x264vfw? The help file says this:
Input/Output:

-o, --output <string> Specify output file
--muxer <string> Specify output container format ["auto"]
- auto, raw, mkv, flv, mp4, avi

I tried "--muxer mp4", but it wont work.

Blue_MiSfit:
For that I have to change the output to File instead of VFW, right?
Thats doesnt work for some reason.

[Dark Shikari]

On ultrafast CPU usage is about 5% lower than on veryfast.Ultrafast is ~4 times faster than veryfast. If you only see a 5% CPU reduction, you have something extremely wrong with your setup, something which using another encoder cannot possibly fix, because the problem isn't the encoder.

[Huddler]

I see 45% CPU usage with a dual core, and with veryfast its around 50%. I find that quite a lot of savings, since its not only the encoder drawing CPU power but also the preview window and the program that I use the plugin in, which I cant separate when encoding.

And no, its not a very fast system, why else do you think I am trying to save CPU power?

Anyway, if its so much faster, why did you first say that its completely pointless to use then? That was the whole point of this thread: To save CPU usage while maybe even improving quality and lowering the file size.

[Dark Shikari]

Anyway, if its so much faster, why did you first say that its completely pointless to use then?Because the compression is truly terrible, and even a slower CPU should be able to afford better. You mentioned Quick Sync, which implies that your CPU is a modern Nehalem-or-later system. Even a very low-end i3 can probably encode 720p30 on "superfast" in realtime with less than one core.

[Huddler]

As I said, mine cant with what its doing in the background. I am trying to save CPU power so it wont slow down as much. 1080p does not work for example, because then the whole computer slows down to a crawl and is unusable they way I want to use it.

I need the PC to have reserves for something like Google Earth, a small game or Flash, etc.

Even right now I'm making a compromise already by not switching the overlay on, because it would slow down the system so much that there will be sound sync issues in the recorded videos.

Of course I have already noticed that ultrafast has a much lower quality, but that isnt such an issue in my case. Its only a webcam anyway, after all. Low CPU usage is more important.