h a l f b a k e r yReformatted to fit your screen.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Firewire cameras do a great job of playing back video in real time, but a problem arises when trying to transfer it to a computer. Since it utilizes a streaming transfer protocol, there is no room for error. If a frame is lost in transmission, it is lost forever. No going back to get it.
Instead,
use a packet based transfer system. The camera sends out fram packets, waiting for the ACK from the computer. If it loses a frame, the camera simply sends it again, not losing a single frame. This may result in a total delay of a few seconds behind real-time, but for captures, who cares?
When connected to a non-capture device, it will stream normally.
[link]
|
|
The reason video transfer is done in real time is because a DV video camera records onto and plays back from a tape. Stopping and starting the tape at exactly the right frame when your computer glitches is not an efficient solution to the problem. |
|
|
An easier way to stop computer glitches is to get a fast hard disk drive and plenty of RAM. |
|
|
It need not start and stop the tape. Simply give the camera a slightly larger buffer. How do you think computer tape drives work? |
|
|
Even a high end machine will experience periodic frame loss, especially those running a certain unnamed operating system. I've even used dedecated mac workstations with an unsatisfactory number of lost frames. This will also allow the computer to perform other tasks simultaniously without risk of loss. |
|
|
I can see where you're coming from, but I think creating a new protocol is a bit of overkill... whether you have a RAM buffer in the video camera or in the computer is (or rather should be) immaterial. It must be possible to optimize operating systems for tasks such as video transfer (or maybe I'm dreaming). |
|
|
Not having ever used a modern video
camera, I had naïvely assumed that they
already worked as Aq_Bi describes. [+]. |
|
| |