Thread: RE: My wishlist entry
Brought to you by:
aeb,
bencollins
From: Arne S. <ar...@sc...> - 2000-04-25 16:27:11
|
Re: dropped frames on sending I mean the opposite... a buffer underrun. If Windows98 does not complain if it can't write to disk fast enough, it probably won't complain if it can't read fast enough. My point is, I don't trust Windows98 in this aspect. Re: iso receive buffer size A command line option for the buffer size is all *I* would like to have. No need for any automatism though. As long as this feature is not there, I simply edit the source and recompile, but not all Linux users are capable of doing that (which is perfectly okay, not everybody is a programmer nor wants to install the many, many MBytes of developer related files and learn how to use it). My opinion is, if we want mainstream Linux users with slow systems using the Linux 1394 system for DV, then we need a command line option for the buffer size or another way to set the size. Cheers, Arne -----Original Message----- From: Andreas Bombe [SMTP:and...@mu...] Sent: Tuesday, April 25, 2000 5:23 AM To: Arne Schirmacher Cc: lin...@li... Subject: Re: My wishlist entry Working up some old mails here... On Sat, Apr 15, 2000 at 09:28:05AM +0200, Arne Schirmacher wrote: > 1. the iso write function. > > My motivation for writing the dvgrab program was that the Windows98 grab > software available to me was too awkward to use. File size limits, no split > into smaller files, no control about dropped frames and the like. Now, after > dvgrab is useable, I discovered that the write-back-to-the-camcorder function > of my Windows98 program suffers from the same deficits too. > > In particular: It will write only one file to the camcorder, it has a file size > limit, the user is not informed about dropped frames, it will not write all > types of DV-AVI files. How can dropped frames when sending be detected? (I'm assuming isochronous sending here.) If it leaves the local computer successfully there is no telling whether it will be received and processed by the target node, since there is no target node. Iso is broadcast and therefore there are no acks. > 2. a way of controlling the device driver's buffer size > > The 1394 subsystem currently uses a buffer size of 4 MByte, which is hardcoded > in raw1394.c. I always have a problem with hardcoded limits, they are always > either too big or too small. This was just a quick hack to keep slow systems from drowning in stored iso packets. I'd like to allocate at buffer priority and free iso packets when memory is needed for real, but that seems to be hard. So the hard limit will probably stay, making it configurable won't be too hard. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Arne S. <ar...@sc...> - 2000-04-27 18:42:51
|
I wanted to modify my dvgrab code, but dvgrab uses libraw 0.6, no direct dma available there :-( [ yet? :-) ] Arne -----Original Message----- From: Sebastien Rougeaux [SMTP:Seb...@sy...] Sent: Wednesday, April 26, 2000 1:08 AM To: ar...@sc... Cc: and...@mu...; lin...@li... Subject: Re: My wishlist entry If I may suggest, you should try the new direct dma to user space feature I have announced the other day for the ohci driver. You can set the buffer size to the size of your dv encoded frame at run-time (it even does multi-buffering), and you save quite a bit of CPU time (the ohci hardware does frame sync and packet header/trailer stripping for you)... Definitely a must use for video acquisition, and I would welcome any feedback on it ;-) -- Sebastien Rougeaux RSISE, The Australian National University |
From: Sebastien R. <Seb...@sy...> - 2000-04-27 23:29:23
|
>>>>> "Arne" == Arne Schirmacher <ar...@sc...> writes: Arne> I wanted to modify my dvgrab code, but dvgrab uses libraw 0.6, no direct Arne> dma available there :-( [ yet? :-) ] Sorry for the confusion. I might not have been explicit enough. Direct user space dma and libraw are completely independent (for the moment). You use libraw to initialize the camera (everything you did before, except you do not need the iso_handler, and you DO NOT use raw1394_start_iso_rcv() nor the raw1394_loop_iterate(). Then you use /dev/ohci1394 as a frame grabbing device, following the instructions I have given in my previous announcement. I have already two successful users for this feature ;-), so it should work. Feel free to ask any question you might have, -- Sebastien Rougeaux RSISE, The Australian National University |
From: Arne S. <ar...@sc...> - 2000-05-01 09:42:24
|
Aren't you already discussing this feature with Andreas in the thread "updated dma to user space API"? I don't want to spend some effort on this if this feature will be available in libraw 0.x anyway. How should a frame grabbing routine using dma be implemented? The naive solution (used in dvgrab up to 0.6x) was: throw away any packet which is 16 bytes long wait until first packet for frame is received put packet into frame buffer until it is filled This would be easy to implement using dma but has several drawbacks: 1. It assumes that packets always come in the required order. I do not know whether this assumption always holds for any type of camcorder. 2. If we lose just one packet this will result in the loss of a full frame, because the next "start of frame" packet will be put in the last position in the previous frame. Therefore synchronization is lost until we get another "start of frame" packet, which is one frame away. Also the current frame is completely broken because all packets from now on are in the wrong place Starting with dvgrab 0.7 I am using a somewhat more robust algorithm which explicitly calculates the packet offset in the frame buffer. If we lose a packet the corresponding area in the frame buffer still contains the previous packet. The assembled frame is "less wrong" than with the naive approach. One tester said he had better results with the new algorithm. But... I can calculate the offset only after I have the packet. So the only way to do it would be predicting the expected address and verifying the packet after it comes in. If the verification fail I have to do some form of smart recovery. Any comments? Arne -----Original Message----- From: Sebastien Rougeaux [SMTP:Seb...@sy...] Sent: Friday, April 28, 2000 1:23 AM To: ar...@sc... Cc: Seb...@sy...; and...@mu...; lin...@li... Subject: Re: My wishlist entry >>>>> "Arne" == Arne Schirmacher <ar...@sc...> writes: Arne> I wanted to modify my dvgrab code, but dvgrab uses libraw 0.6, no direct Arne> dma available there :-( [ yet? :-) ] Sorry for the confusion. I might not have been explicit enough. Direct user space dma and libraw are completely independent (for the moment). You use libraw to initialize the camera (everything you did before, except you do not need the iso_handler, and you DO NOT use raw1394_start_iso_rcv() nor the raw1394_loop_iterate(). Then you use /dev/ohci1394 as a frame grabbing device, following the instructions I have given in my previous announcement. I have already two successful users for this feature ;-), so it should work. Feel free to ask any question you might have, -- Sebastien Rougeaux RSISE, The Australian National University |
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 |
From: Simon V. <si...@tk...> - 2000-05-02 06:45:09
|
Hi all, the header bytes in the DV data blocks let you compute the correct address where the video data should go to, so if you write your codec in the right way, you'll have some blocks missing, but that's all. Windows will need its fixed buffer length for a frame, but that's all, I think. I think the more likely event to occur is tape problems which result in error blocks being sent over the wire, which do not contain any video information, but that's a different story :) Simon > > 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 > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel > -- --------------------------------------------------------------------------- si...@tk... - icq: 14088682 - www.tk.uni-linz.ac.at/~simon I2C-Bus 4 Linux: www.voxel.at/prj/i2c/ |
From: Sebastien R. <Seb...@sy...> - 2000-04-25 23:15:13
|
>>>>> "Arne" == Arne Schirmacher <ar...@sc...> writes: Arne> A command line option for the buffer size is all *I* would like to Arne> have. No need for any automatism though. As long as this feature is not Arne> there, I simply edit the source and recompile, but not all Linux users Arne> are capable of doing that (which is perfectly okay, not everybody is a Arne> programmer nor wants to install the many, many MBytes of developer Arne> related files and learn how to use it). Arne> My opinion is, if we want mainstream Linux users with slow systems using Arne> the Linux 1394 system for DV, then we need a command line option for the Arne> buffer size or another way to set the size. If I may suggest, you should try the new direct dma to user space feature I have announced the other day for the ohci driver. You can set the buffer size to the size of your dv encoded frame at run-time (it even does multi-buffering), and you save quite a bit of CPU time (the ohci hardware does frame sync and packet header/trailer stripping for you)... Definitely a must use for video acquisition, and I would welcome any feedback on it ;-) -- Sebastien Rougeaux RSISE, The Australian National University |