|
|
| dipswitch |
| Posted: Apr 8 2003, 09:32 AM |
 |
|
Unregistered
|
Since capturing hardware-compressed MJPEG direct-stream gives garbage frames sometimes, I have to capture uncompressed RGB but that's all so big (5-10 MB/s). I tried software MJPEG compression on uncompressed input data but my CPU (AMD Duron 1.7 GHz) can't keep up, especially in action scenes - it drops about 20% of the frames. Other software compression codecs are even slower. The HD is fast enough for everything instead.
What's the best codec for fast, light, real-time compression? Even low compression rates will do, maybe just 2:1 or 3:1 - just to squeeze the typical 60 GB required to something less, so I won't have to get a new HD for that.
I'm capturing PAL input at 352x288 and full (25) fps.
If a good codec was found, I'd like to upgrade to 352x576 - the difference IS noticeable.
Thank you.
|
|
| valja |
| Posted: Apr 8 2003, 09:51 AM |
|
|
Advanced Member
Group: Members
Posts: 179
Member No.: 66
Joined: 1-August 02
|
I think Huffyuv codec is just for you, it's lossless, probably best for capture.
If you need more details, use "search", this codec has been discussed here more than oncre.
|
|
| endorphin |
| Posted: Apr 8 2003, 04:39 PM |
|
|
Advanced Member
Group: Members
Posts: 112
Member No.: 3488
Joined: 4-April 03
|
He's right -- dipswitch, you are describing Ben Rudiak-Gould's HuffYUV codec perfectly. It's both lossless and fast. It has several options allowing you to trade CPU intensity against compression ratio. Best of all it keeps the video in its native YUV format (assuming it wasn't converted to RGB by your method of transfer from the camera) to avoid unnecessary colorspace conversion.
Here's the Link |
|
| Belgabor |
| Posted: Apr 8 2003, 11:13 PM |
|
|
Developer of VirtualdubMod
Group: VirtualdubMod Team
Posts: 100
Member No.: 998
Joined: 24-November 02
|
Don't forget to capture in YUY2 if you use HuffYUV.
--------------------
[VirtualDubMod Homepage]
Please submit any bugs/patches/feature requests also using the respective tracker on our sourceforge page |
|
| endorphin |
| Posted: Apr 9 2003, 03:57 AM |
|
|
Advanced Member
Group: Members
Posts: 112
Member No.: 3488
Joined: 4-April 03
|
Dipswitch -- I just read your post a second time. A 1.7GHz Duron should by all means be able to handle encoding to MJPEG, even if software encoding, and *especially* if it has a hardware MJPEG engine installed. There's no way a 1.7GHz CPU is too slow for the task.
Therefore you probably have other things about your computer that are interfering with a smooth flow of data over the PCI bus from your input device to your hard drive(s). If I may assume that you're using Windows, there's a very long list of things you can do to prevent your operating system from getting in the way (and it usually is, if you haven't spent some time reconfiguring it to handle continuous video transfer).
Windows was not created specifically with the task of capturing video (or maintaining other large data transfers for a long time without interruption). It is very good at moving data back and forth as long as it doesn't matter when the data gets there. If you need the data to get there on time, over and over for many minutes, then you need to do some housecleaning. If you're running Windows NT, 2000, or XP, there are a bunch of Windows "services" you need to turn off temporarily or for good. See www.blackviper.com for a useful list of what services you can get away with stopping.
Some peripherals and their drivers can cause a Windows system (any version) to burp from time to time and interrupt a capture. Some printers check every few seconds to see if they have any more work to do. Some memory card readers check to see if there is any new card to read. Drivers should not work this way but some of them do, what can I say.
Do you know what motherboard you have in your computer? If by chance it's based on a VIA chipset, there is a PCI Latency Patch available at http://www.georgebreese.com/net/software/ which can greatly improve your situation for any large scale data transfers like video capture, as well as large file drive-to-drive copying.
There is much much more to the issue of dropped frames, but these are the main points. Every little thing you can do to simplify your system and cut out any unnecessary stuff that is running in the background will help, until eventually you'll find a configuration that allows you to capture with no dropped frames -- ever. Even in MJPEG or HuffYUV. Good luck, persistence pays off. It's not like trying to find a secret combination. Just ruthlessly remove devices and deactivate background programs and services until you simplify enough to make it capture cleanly.
This should maybe be filed under Capture rather than Codecs.
|
|
| dipswitch |
| Posted: Apr 11 2003, 11:43 AM |
|
|
Unregistered
|
Hey, you know what?
I got HuffYUV and it works perfectly with 352x288 video, giving an approx. 3:1 ratio. Very good.
But it's not fast enough for 352x576. That's impossible! I don't want to halve the resolution but I can't capture uncompressed... I tried that using RGB16 only to find out that AVISynth can't deal with RGB16... and RGB24 is beyond the size of my disk. Unluckily, my video card can't capture YUV.
I'll try and stop some background services as you suggested, but the whole thing sounds very strange to me...
Thank you. |
|
| endorphin |
| Posted: Apr 12 2003, 03:29 AM |
|
|
Advanced Member
Group: Members
Posts: 112
Member No.: 3488
Joined: 4-April 03
|
Good luck!
Tell us how it goes. |
|
| dipswitch |
| Posted: Apr 12 2003, 12:09 PM |
|
|
Unregistered
|
I solved the problem!
It's unbelievable. Before, at 352x288 HuffYUV took up about 80% CPU time, so at 352x576 I was hopeless.
I thought I had tried all the different YUV modes in the Custom Format dialog, so I believed I could only do RGB. But I tried them all again, and I found that one of these modes actually works. And here's the strange part. It doesn't work every time. Sometimes the capture process starts but no frames are captured, but sometimes it captures correctly. And when capturing YUV instead of RGB, at 352x576 the CPU time used is less than 10% for a 3:1 ratio!!! And just above 20% for 704x576. Incredible.
Thank you all guys, sorry you wasted time on a problem that was so easy to solve - well, if one knew how to do it.
Thanks again for being so kind and friendly. |
|
