Re: My wishlist entry
Brought to you by:
aeb,
bencollins
From: Sebastien R. <Seb...@sy...> - 2000-05-02 06:32:46
|
>>>>> "Arne" == Arne Schirmacher <ar...@sc...> writes: Arne> Aren't you already discussing this feature with Andreas in the thread Arne> "updated dma to user space API"? I don't want to spend some effort on Arne> this if this feature will be available in libraw 0.x anyway. Yes, the current API is probably temporary... but since I don't have much free time, it might stay like that for a while. Currently, it works the following way in the ohci driver: The dma prg wait for an iso packet with the correct 'sync tag'. Then it fills the frame buffer with the data it receives until it is full. The dma prg removes all packet header/trailers, so what you have at the end in the buffer is a complete properly formatted image (for uncompressed video), or a complete dv encoded frame. At the completion of the frame, it generates an interrupt in order to wake up the user app which is waiting for frame completion. All is done using the dma engine of the ohci card, so CPU usage is kept to a minimum. Arne> How should a frame grabbing routine using dma be implemented? Arne> The naive solution (used in dvgrab up to 0.6x) was: Arne> throw away any packet which is 16 bytes long wait until first packet for Arne> frame is received put packet into frame buffer until it is filled Arne> This would be easy to implement using dma but has several drawbacks: Arne> 1. It assumes that packets always come in the required order. I do not Arne> know whether this assumption always holds for any type of camcorder. It would be strange otherwise... Arne> 2. If we lose just one packet this will result in the loss of a full Arne> frame, because the next "start of frame" packet will be put in the last Arne> position in the previous frame. Therefore synchronization is lost until Arne> we get another "start of frame" packet, which is one frame away. Also Arne> the current frame is completely broken because all packets from now on Arne> are in the wrong place If you loose the sync packet, then there is little you can do... Arne> Starting with dvgrab 0.7 I am using a somewhat more robust algorithm Arne> which explicitly calculates the packet offset in the frame buffer. If we Arne> lose a packet the corresponding area in the frame buffer still contains Arne> the previous packet. The assembled frame is "less wrong" than with the Arne> naive approach. One tester said he had better results with the new Arne> algorithm. Arne> But... I can calculate the offset only after I have the packet. So the Arne> only way to do it would be predicting the expected address and verifying Arne> the packet after it comes in. If the verification fail I have to do some Arne> form of smart recovery. How can you know that you lost a packet, and which area of the image it correspond to ? I think anyway loosing a packet is a 'rare' event, especially if you use the dma prg I am describing at the beginning of this mail, so the effect in the video stream should be barely noticable. -- Sebastien Rougeaux RSISE, The Australian National University |