linux1394-devel

announce: dvgrab 0.6

[Arne S. <ar...@sc...>]

Hi all,

a new version of dvgrab is available. Download it from 
http://www.schirmacher.de/arne/dvgrab/ .It also has some documentation in 
english and german language and links to other 1394 and DV related resources.

The biggest advantage is a new feature which I named "autosplit". It checks 
certain flags in the DV data to see whether the current frame belongs to a new 
recording. If so, it creates a new AVI file for this new recording. It will 
also create new AVI files whenever the requested number of frames is exceeded 
or when the AVI file reaches the 2 GByte file size limit.

What you can do now (and I like this feature really): hook up your camcorder, 
fire up dvgrab and one hour later you have a neat collection of lots of AVI 
files each having its own scenes. This is really useful, because most video 
editing software works better with a number of smaller files instead of a 
single huge one. And you have a workaround for that 2 GByte file size limit 
too.

The program is now in C++. The main reason for it is that the RIFF/AVI file 
format leads to an OO-approach naturally, and I also got exception handling and 
less global variables by doing the port. Let me know whether you like it.

Arne

Re: announce: dvgrab 0.6

[Andreas B. <and...@mu...>]

On Thu, Apr 06, 2000 at 06:30:28PM +0200, Arne Schirmacher wrote:
> The biggest advantage is a new feature which I named "autosplit". It checks 
> certain flags in the DV data to see whether the current frame belongs to a new 
> recording. If so, it creates a new AVI file for this new recording. It will 
> also create new AVI files whenever the requested number of frames is exceeded 
> or when the AVI file reaches the 2 GByte file size limit.

Regarding the 2GB limit: current 2.3 kernels should be able to do more
(even on 32 bit machines).  In part it was also an intended limitation
in order not to break the APIs (lseek() has to be able to do relative
seeks from one end to the other).

The API issues are resolved with current glibcs.  Either use the 64
bit functions (open64, lseek64 etc.) or define _FILE_OFFSET_BITS to 64
then the standard open etc. calls will run in large file mode.

-- 
 Andreas E. Bombe <and...@mu...>    DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/    http://linux1394.sourceforge.net/