dvgrab R E L E A S E   N O T E S

-------
v3.5
-------
* Automatically detect DV vs. HDV when not using -noavc, -input, or -stdin.
* Now waits indefinitely for DV or HDV instead of giving up after 10 seconds.
* Bugfixes

-------
v3.4
-------
* Fix a showstopping bug in the v3.3 release

-------
v3.3
-------
* Give different warnings for dropped versus damaged frames
* Bugfixes

-------
v3.2
-------
* New -srt option to write subtitle files containing recordind date/time
* New -recordonly (-r) option for use with camcorder record (camera) mode
* New -rewind option to rewind tape to beginning before starting capture
* Added automatic stop capture at end of tape
* Added optional seconds argument to autosplit
* Improved autosplit
* Bugfixes and updated documentation

-------
v3.1
-------
* New -jvc-p25 option to post-process JVC P25 streams for interoperability
* Fix regression on broken pipe output
* Improved HDV handling
* New -24p and -24pa options for Quicktime DV for 24 fps modes

-------
v3.0
-------
* Add HDV (MPEG2-TS) support (-f hdv)!
* Add USB DV support (-v4l2)
* Simpler and more flexible option parsing
* Bugfixes and updated documentation

-------
v2.1
-------
* Add feature to not capture/write-to-file when device is paused while in
  recording mode. This depends upon the device sending timecode as all
  zeroes while in that state.
* Changed --jpeg-overwrite so it does not generate a sequentially numbered
  filename or filename containing recording date or timecode. This makes
  dvgrab work nicely with StopMotion (http://stopmotion.bjoernen.com/).
* Bugfixes with dropped frame counting and quicktime support.

-------
v2.0
-------
This release exclusively uses the new third generation Linux IEEE 1394 capture
API available in raw1394 and libiec61883. The libiec61883 provides a protocol-
specific layer over the raw foundation. This new approach is both robust and
simpler than using protocol-specific kernel modules such as dv1394. As a result,
dvgrab 2.0 requires Linux kernel 2.4.20 or newer.

Usage of the connection management procedures in libiec61883 also makes it
rather easy to capture from multiple DV devices on the same bus by using the
--guid option. This feature is not entirely foolproof due to the inconsistency
of implementations of devices, but you can try. Most devices are only running
at 100mbps speed, which limits it to two DV streams per bus. However, through
dip switches or the output master plug register, some devices can run at 200 or
400 and therefore more streams can exist on the bus. For example, I have tested
four Canopus ADVC-500 devices on a single bus using the connection management
procedures. Also, multiple host adapters are transparently supported when using
the --guid option.

Like dvconnect, now dvgrab will schedule with realtime scheduling policy and
lock all memory resident to prevent paging when run with super user permission.

New options "--lockstep" and "--timecode" can be used together to provide a
redundant capture system where multiple Linux hosts can capture from the
same bus without knowledge of each other and still produce output files with 
the same name for the same segment of video.

-------
v1.7
-------
This release fixes a few bugs related to deadlocks when stopping a dv1394 
capture and file permissions. Also, --duration should be slightly more accurate
especially for specifying 1 frame: --duration smpte=:::1.

P.S. You can capture a specific number of frames using --duration smpte=:::X
whereas the --frames option is used for file splitting.

-------
v1.6
-------
This is an enhancement release with some bug and compilation fixes. New options
are --timesys for timestamping filenames using the system date and time, 
and --csize, and --cmincutsize for fine-grained control over sizes of 
collections of files useful for creating archives to CD or DVD.

-------
v1.5
-------

This is a bugfix release. There were bugs in the AVI file creation especially
for files near or greater than 1GB. Also, the --every option was broken in
the past 2 releases. There are also changes to make dvgrab behave nicer when
a camera is in camera mode rather than VTR mode. Finally, --autosplit is
enhanced to check timecode discontinuity as well as the special flag in the
DV stream.


----
v1.4
----
This is mainly a bugfix release. To prevent issues with dvgrab running in a
non-interactive shell script, dvgrab now requires the --stdin option to
read DV from a pipe. Also, option --noavc was added to prevent any attempt
to control the camera, which is especially useful if you are capturing from
your device in camera mode as opposed to VTR mode. Another new option --guid
lets you select from more than one device by its GUID (see
/proc/bus/ieee1394/devices to lookup a GUID). Finally, some changes were made
in the AVI file to reduce memory consumption on very large file captures and
to prevent occasional segfaults.

----
v1.3
----
This is a major release prepared by Dan Dennedy that adds AV/C control and
an interactive mode. The default mode of operation is non-interactive to 
prevent breaking existing users' scripts. However, dvgrab 1.3 will issue
an AV/C command to tell the camera VTR to start playing. Therefore, dvcont
may no longer be required. However, heed caution! If your camera is not in VTR
mode, but is in camera mode, the play command tells the camera to start 
recording!

One enters interactive mode by supplying the -i or --interactive options.
From there, the command prompt describes the single key presses available
to control the camera and start/stop capture.

All dvgrab 1.3 messages are written to stderr (normally connected to your
terminal so you can see them) and include a consistent, easy-to-parse format 
for status, event, and error messages.

dvgrab 1.3 can also write raw DV to stdout while simultaneously capturing to 
a file. This behavior is automatic when you redirect stdout or pipe the command.
This is especially nice with recent versions of Xine and mplayer as they
can display DV with deinterlacing and adjusting for the non-square pixel aspect
ratio of DV. For example,
dvgrab -i | xine -D stdin://#demux:rawdv

The last part of the Xine MRL in the line above is important; otherwise, xine
does not know the data format of the pipe!

All of the above means one can build a user interface frontend (non-GPL even)
to dvgrab by fork()ing and exec()ing dvgrab with pipes established between the
frontend and dvgrab.

Building upon the pipe capabilities, in non-interactive mode dvgrab 1.3 accepts
raw DV on stdin. If detected, dvgrab forgoes any 1394-based capture method.
This allows one to leverage the file format writing and splitting options of
dvgrab in conjunction with raw DV producers such as smilutils and ffmpeg.

A grand new option is --duration, which specifies a maximum duration for
an entire capture session regardless of splitting. Furthermore, the argument
to this option is specified in SMIL2 time value formats, which is quite
expressive. Note, that in interactive mode, starting capture starts a new
session. Thus, in interactive mode, you can have multiple capture sessions
by stopping and re-starting.

Additional changes include some friendlier defaults and automatic options.
dvgrab 1.3 will look on all your 1394 buses/host adapters for your camera
without the explicit --card opion. It selects the first camera discovered.
Type 2 AVI is now the default file format for increased compatibility with
other applications. Now, supplying --frames and --size options that cause
dvgrab to generate an AVI >1GB automatically enables the --opendml option.
Finally, the base filename argument is optional now too and defaults to
"dvgrab-".

----
v1.2
----

This release is a major new release prepared by Dan Dennedy that pulls in
much of what improved upon in Kino plus more.

AVI file correctness and compatibility has been improved upon. 
1.1 beta releases allowed one to specify small and large indexes.
This is no longer required; it is automatic now based upon general
practice observed in AVIs created by other applications. Instead, 
now there is a new --opendml option for use with type 2 DV AVI 
(--format dv2).

OpenDML is a specification of AVI extensions created by Matrox in
collaboration with others and approved by Microsoft. OpenDML 
introduced a new index structure, which dvgrab 1.1 called the 
"large" index. Type 1 DV AVI (dv1) is inherently OpenDML,
and it contains a large index only. dvgrab 1.2 type 2 always contain 
a small index, but OpenDML adds a large index to permit type 2 AVIs 
greater than 1GB. 

The main difference between a type 1 and type 2 file is that a type 2 
contains a separate audio stream extracted from the DV. dvgrab 1.2
can use libdv (must be detected when compiled) to create this audio stream
instead of using internal routines. There are several advantages of 
using libdv the most obvious being audio block error handling. Without
error handling, one can hear "bleeps" in the audio stream.

Raw DV capture has been improved to prevent corrupt files in the event of
a dropped firewire packet. Also, one can send raw DV to stdout instead
of to a file, so it can be used in pipes. This is especially useful with
smilutils. For example, one can preview video with libdv's playdv utility:
dvgrab - | playdv --no-mmap
The '-' file designation forces the format to raw overridding whatever
you specify; the other formats are not streaming formats.

Support for Quicktime has been added if libquicktime is detected when
compiled. Use "--format qt." It creates a separate audio track in twos
complement format.

Support for JPEG has been added if jpeglib is deteced when compiled.
Use "--format jpeg" to save a series of sequentially numbered JPEG
still images. There are two number parts of the filename, the first number
is increments with each scene change while the second number increments
with each successive save. Use --jpeg-overwrite to continually update the
same file and not add any numbers to the file name stem you provide. The
JPEG option works nicely with the --every option.

There are several JPEG options you will find handy. First, is --jpeg-quality
followed by a number between 0 and 100; the default is 75.
--jpeg-deinterlace extracts one of the fields and doubles it for a cheap
form of deinterlacing. However, when used with the scaling options 
--jpeg-width and --jpeg-height to reduce the resolution by 50%, 
you can get perfect deinterlaced output. The scaling
options also allow one to compensate for the non-square pixels of DV.
For example, on NTSC, the following produces nice output for a webcam,
dvgrab --format jpeg --jpeg-deinterlace --jpeg-width 320 --jpeg-height 240

Due to code refactorization, all capture options work with all formats.
For example, previous versions of dvgrab did not support hardly any
options like --autosplit, --every, --timestamp, and --frames when used
with --format raw. 

A new capture option --size followed by a number in mega bytes, sets 
the maximum file size of any captured file.

If all this were not enough; dvgrab 1.2 also supports capture using the 
new dv1394 driver! See http://www.linux1394.org/dv1394.html for more
information on this driver. By default and traditionally, dvgrab uses 
raw1394; however, raw1394 requires an interrupt for each packet, which
can be too intense for some systems. dv1394 in kernel releases 2.4.21 or
recent linux1394.org Subversion snapshots drastically reduce the IRQ and
using kernel background threads and internal buffering. You must use the
--dv1394 option followed by the device file name to use dv1394 instead
of raw1394.
