Menu
▾
▴
libdv-dev
|
From: Arne S. <ar...@sc...> - 2000-05-01 09:42:24
|
Well, I didn't actually wrote the xdvplay program, I just added a couple of
calls to my AVI library to the existing playdv.c program.
Here is what I think is needed most:
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 (early versions of libraw suffered from the same problem and the
author had to fix it). 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.
This would be the first thing to do, just to allow other people start working.
If we have this I would try to merge it with an existing player software like
xanim for example.
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.
When I have my SuSE 6.4 DVD (due May 10), I am going to buy a TV card and play
with this whole v4l thing and also with broadcast2000. Right now my system is
so outdated that these programs do not work at all. Dvgrab runs fine though...
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.
4. Stability, Quality. Right now libdv is a bit, er... , sensitive to its input
data. If it is invalid data it just crashes. The DV data stream from a
camcorder is not guaranteed to be error-free, packets may be dropped, the
program should not crash if it is feed with wrong data.
Arne
-----Original Message-----
From: Erik Walthinsen [SMTP:om...@cs...]
Sent: Monday, May 01, 2000 1:21 AM
To: Arne Schirmacher
Cc: lib...@li...
Subject: Re: xdvplay 0.2 is available
On Sun, 30 Apr 2000, Arne Schirmacher wrote:
> This is a slightly modified version of the playdv.c program from the libdv
> project. This version now reads AVI files instead of plain DV data files.
The plan is to convert libdv into a real library in the near future.
Since you've actually written an application with it, you're probably good
resource for ideas on the exact API. What are your thoughts on that
matter? Check the archives for a few ideas (at least, it's supposed to be
in the archives, let me know if you can't find it) we've had so far.
Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI
Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
__
/ \ SEUL: Simple End-User Linux - http://www.seul.org/
| | M E G A Helping Linux become THE choice
_\ /_ for the home or office user
|
|
From: James B. <ja...@ex...> - 2000-05-01 14:31:04
|
Arne Schirmacher wrote: ... > 4. Stability, Quality. Right now libdv is a bit, er... , sensitive to its input > data. If it is invalid data it just crashes. The DV data stream from a > camcorder is not guaranteed to be error-free, packets may be dropped, the > program should not crash if it is feed with wrong data. Could we start a collection of data streams with errors? -- James Bowman ja...@ex... |
|
From: Alastair M. <ala...@aj...> - 2000-05-01 17:51:21
|
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 |
