Re: [libdv-dev] RE: xdvplay 0.2 is available

[Alastair M. <ala...@aj...>]

Just adding my 2 cents worth:

Arne Schirmacher wrote:

[some snippage may have occurred]

> 1. make a library. That shouldn't be too difficult. Just put all your *.o files
> into a lib and write a public header file. Please make it g++ compatible from
> the start

Ditto.  I tend to favor C++ for apps.  This doesn't necessarily mean
coming up
with class wrappers, just so long as g++ doesn't barf on the C code.

> ... My first guess would be int dv_decode(void
> *compressed_data, void *uncompressed_data, struct some_dv_info *info). The info
> struct should have some basic information like width, height, result code etc.
> The pointer compressed_data is one full frame of NTSC or PAL data.
> Uncompressed_data should be the RGB format as it is used in playdv.c right now.

Who handles the audio stream(s)?  Is the split done upstream of,
downstream of,
or by the dv_decode()?  (Probably by it, perhaps also with options or
alternate
functions to return just the image data or just one or more audio
channel data.)

Also, some flags/options/whatever to discriminate between interlaced and
progressive
video streams (is there anything in the signal that indicates this or
does the user
just have to know?) and perhaps provide for de-interlacing (scan
doubling with
optional doubling the frame rate).   Yes, this can all be done by the
application
post-decompression if you really don't want it here.

For editing apps (eg Broadcast 2000 mentioned below, although I don't
know if that
one supports it) some way of getting at timecode data is useful.

An alternative to simply returning pointers to various uncompressed data
streams
might be to provide for pointers to functions that get called for the
various data
streams at the end of each frame.   The former would likely be more
useful in editing
apps, the latter more useful in playback apps.

> 2. make a video4linux compatible framework. I do not have any experience with
> v4l or v4l2, but since it is supposed to be a general purpose framework, we
> should extend it such that a camcorder with the ieee1394 subsystem and libdv
> codec can be used just as any other TV frame grabbing card. Only with superior
> quality of course.

I like this idea. It'd be nice to have xawtv or whatever able to play
1394 dv cam
input as well as composite or tuner input.  (How well apps like xawtv
are structured
to make this simple I don't know.  In an ideal world there might be some
sort of
general "stream of images" connection the way most files are considered
"stream of
characters", with lower level layers taking care of what kind of stream
that really is.)

> 3. Broadcast2000 support. I did not try it yet, don't know what is required for
> supporting it, but having DV support in broadcast2000 would be very cool.

Bcast 2000 officially doesn't support DV because the author doesn't have
any DV
equipment.  But yes, it'd be a nice addition.  (Personally I haven't had
much success
with any sort of video under bcast2000, but have used its audio
capabilities quite a
bit.  There are some UI things I'd change.  It'd be nice to see a
NLE/compositing suite
for Linux that can handle almost any format via plugins.)

Cheers,
 -- Alastair