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/ |