Thread: My wishlist entry
Brought to you by:
aeb,
bencollins
From: Arne S. <ar...@sc...> - 2000-04-15 07:46:16
|
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. So, once I have the iso write function (or whatever is needed to write data to a camcorder), I would like to make a program that will write several AVI files in one session, provides feedback about data over-/underrun and supports more than one flavour of AVI file. 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. One size doesn't fit all. With my somewhat dated hardware system (AMD 333, slow IDE disks) I have to change this limit to 24 MByte to avoid any data loss. Smaller buffer sizes eventually result in dropped frames. Remember that I use dvgrab to copy whole tapes to disk, usually 10 GByte in one session. My suggestion would be a command line option at insmod time (buf=24M for example). Arne |
From: Andreas B. <and...@mu...> - 2000-04-25 03:45:37
|
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/ |