Menu
▾
▴
libdv-dev
This list is closed, nobody may subscribe to it.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(36) |
May
(15) |
Jun
(7) |
Jul
(8) |
Aug
(15) |
Sep
(3) |
Oct
(2) |
Nov
(59) |
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(43) |
Feb
(11) |
Mar
(10) |
Apr
(39) |
May
(22) |
Jun
(25) |
Jul
(10) |
Aug
(4) |
Sep
(3) |
Oct
(2) |
Nov
(22) |
Dec
(2) |
| 2002 |
Jan
(4) |
Feb
(20) |
Mar
(50) |
Apr
(13) |
May
(39) |
Jun
(36) |
Jul
(14) |
Aug
(16) |
Sep
(3) |
Oct
(23) |
Nov
(34) |
Dec
(16) |
| 2003 |
Jan
(37) |
Feb
(37) |
Mar
(2) |
Apr
(14) |
May
(10) |
Jun
(23) |
Jul
(33) |
Aug
(16) |
Sep
(27) |
Oct
(17) |
Nov
(76) |
Dec
(10) |
| 2004 |
Jan
(89) |
Feb
(13) |
Mar
(13) |
Apr
(14) |
May
(43) |
Jun
(27) |
Jul
(34) |
Aug
(14) |
Sep
(4) |
Oct
(15) |
Nov
(14) |
Dec
(33) |
| 2005 |
Jan
(9) |
Feb
(4) |
Mar
(12) |
Apr
(19) |
May
|
Jun
(4) |
Jul
(1) |
Aug
(3) |
Sep
(2) |
Oct
(3) |
Nov
|
Dec
(3) |
| 2006 |
Jan
(3) |
Feb
(4) |
Mar
(7) |
Apr
(11) |
May
(3) |
Jun
(7) |
Jul
|
Aug
(8) |
Sep
(11) |
Oct
(2) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(7) |
Nov
(7) |
Dec
|
| 2008 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
(8) |
Jul
(3) |
Aug
|
Sep
(6) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
|
From: Erik W. <om...@cs...> - 2000-11-15 06:49:26
|
On Tue, 14 Nov 2000, Stefan Lucke wrote: > Could anyone provide a short NTSC (SMPTE format) sequence (3 frames) in 16:9 > format for downloading ? There are now two more samples available via FTP: 4x3.dv and 16x9.dv. They are both raw DV, 3 frames each, of the same scene. They were shot with a Canon Elura in normal (interlaced) mode. There should be zero motion in them, except for my finger coming off the enter key ;-) They are at ftp://libdv.sourceforge.net/pub/libdv/ 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: Stefan L. <lu...@sn...> - 2000-11-14 23:38:01
|
On Fre, 03 Nov 2000, lu...@sn... wrote: > Hi, > > does anyone know if there is a flag in the VAUX section (or somewhere else) > which indicates that current video data is in wide screen (16:9) format > and/or anamorphic encoded ? > So now I've got my own version of SMPTE 314M. Format recognition seems to be ok for both (SMPTE/IEC) datastreams. VAUX packet 0x61 has zero DISP for 4:3 format. 16:9 is indicated different (0x02 per SMPTE/0x07 per info of my sample). Could anyone provide a short NTSC (SMPTE format) sequence (3 frames) in 16:9 format for downloading ? -- mfg Stefan Lucke (lu...@sn...) |
|
From: Stefan L. <lu...@sn...> - 2000-11-14 23:38:00
|
On Mon, 13 Nov 2000, Arne Schirmacher wrote: > What about the special commands that are in AMD CPUs? They have MMX too, I'd like that todo too, but notably most 3D extensions are 32bit floats and only a few instructions deal with 2/4/8 (int/shorts/bytes) values in mmx registers. For further processor differentiations there should be probably code to recognize K6/2+ K6/3+ Duron Athlon. They share the same 3D extended instruction set. > but maybe these extra instructions are even faster? > > Btw the MMX recognizing routine in the xvimage patch does not assemble with > my system. One of the macros produced an error. If you can't reproduce it, > I can go back and collect all the details. Please give me more details . [snip] -- mfg Stefan Lucke (lu...@sn...) |
|
From: Arne S. <ar...@sc...> - 2000-11-13 21:48:57
|
Is there an AVI format defined for this video type? If so, please let me have a short AVI file too.
Arne
-----Original Message-----
From: Erik Walthinsen
Sent: Monday, November 13, 2000 12:42 AM
To: Jens Michaelsen
Cc: lib...@li...
Subject: [libdv-dev] Re: DV50
On Fri, 27 Oct 2000, Jens Michaelsen wrote:
> did you try 50MBit DVpro decoding??
> Here they use SDTI instead of FireWire and the
> stuff is coded 422 instead of 420/411.
The SMPTE 314M spec details how it's done, but we don't have any support
for it yet. We're currently in a push to get libdv cleaned up and
hopefully sped up, after which we can look into getting DV50 working. The
problem is that we don't have any way of getting a DV50 stream. If you
can send us a second or two of DV50 in raw form (240,000 bytes per frame)
that'll speed things up immensely.
TTYL,
Omega
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
_______________________________________________
libdv-dev mailing list
lib...@li...
http://lists.sourceforge.net/mailman/listinfo/libdv-dev
|
|
From: Arne S. <ar...@sc...> - 2000-11-13 21:47:51
|
I'll upload my libdv version to http://www.schirmacher.de/tmp/ in a couple of hours. Arne -----Original Message----- From: Charles 'Buck' Krasic Sent: Sunday, November 12, 2000 7:37 PM To: Arne Schirmacher Cc: lib...@li... Subject: Re: [libdv-dev] Consolidation of libdv code? Could you submit a patch for this? I'll integrate it with the other things. I will be doing a CVS commit for the existing patches today. -- Buck _______________________________________________ libdv-dev mailing list lib...@li... http://lists.sourceforge.net/mailman/listinfo/libdv-dev |
|
From: Arne S. <ar...@sc...> - 2000-11-13 21:47:18
|
What about the special commands that are in AMD CPUs? They have MMX too,
but maybe these extra instructions are even faster?
Btw the MMX recognizing routine in the xvimage patch does not assemble with
my system. One of the macros produced an error. If you can't reproduce it,
I can go back and collect all the details.
Arne
-----Original Message-----
From: Stefan Lucke
Sent: Sunday, November 12, 2000 10:54 PM
To: lib...@li...
Subject: [libdv-dev] IDCT-248 mmx
Hi,
is there someone working on this ?
I just started with an mmx version of quant_248_inverse.
For encoding:
there is an error in weight_248:
for (z=0;z<8;z++)
for (x=0;x<8;x++) {
should be
for (z=0;z<4;z++)
for (x=0;x<8;x++) {
to avoid out of bounds addressing of:
block[z*8+x] *= W[x] * W[2*z] / 2;
block[(z+4)*8+x] *= W[x] * W[2*z] / 2;
--
mfg
Stefan Lucke (lu...@sn...)
_______________________________________________
libdv-dev mailing list
lib...@li...
http://lists.sourceforge.net/mailman/listinfo/libdv-dev
|
|
From: Erik W. <om...@cs...> - 2000-11-13 00:42:21
|
On Fri, 27 Oct 2000, Jens Michaelsen wrote:
> did you try 50MBit DVpro decoding??
> Here they use SDTI instead of FireWire and the
> stuff is coded 422 instead of 420/411.
The SMPTE 314M spec details how it's done, but we don't have any support
for it yet. We're currently in a push to get libdv cleaned up and
hopefully sped up, after which we can look into getting DV50 working. The
problem is that we don't have any way of getting a DV50 stream. If you
can send us a second or two of DV50 in raw form (240,000 bytes per frame)
that'll speed things up immensely.
TTYL,
Omega
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: Stefan L. <lu...@sn...> - 2000-11-12 23:04:32
|
Hi,
is there someone working on this ?
I just started with an mmx version of quant_248_inverse.
For encoding:
there is an error in weight_248:
for (z=0;z<8;z++)
for (x=0;x<8;x++) {
should be
for (z=0;z<4;z++)
for (x=0;x<8;x++) {
to avoid out of bounds addressing of:
block[z*8+x] *= W[x] * W[2*z] / 2;
block[(z+4)*8+x] *= W[x] * W[2*z] / 2;
--
mfg
Stefan Lucke (lu...@sn...)
|
|
From: Charles 'B. K. <kr...@ac...> - 2000-11-12 22:53:43
|
Well, I just took the plunge and did a fairly major commit to CVS.
It doesn't have everything yet, but I'm loathe to get too deep into
communicating via patches and tarballs.
I did pretty substantial molestation of the Xv and SDL patches, and
all of the existing post-decode stuff.
ycrcb_to_rgb32.[ch] are have been broken up into a number of separate files:
YV12.[ch] -- preps IEC IEC 61834 PAL for 4:2:0 YUV overlay
YUV2.[ch] -- preps decoded NTSC and SMPTE PAL for 4:2:2 YUV overlay
rgb.[ch] -- prep for gtk rgb24 output
display.[ch] -- interfaces to gtk, Xv, and SDL. The Makefile
allows you to toggle each. The default is to support
all, trying Xv, then SDL, then gtk at startup.
We still need to get library interface pinned down, including C++ friendly.
-- Buck
Stefan Lucke <lu...@sn...> writes:
> I think your (buck's) previous "greeen ring" correction breaks my xvimage patch.
> I made a corrected version and I'll send it to Buck soon.
> > -- Buck
|
|
From: Stefan L. <lu...@sn...> - 2000-11-12 22:19:56
|
On Son, 12 Nov 2000, Charles 'Buck' Krasic wrote: > Arne Schirmacher <ar...@sc...> writes: > > > There are several patches in the libdv repository on sourceforge. Features > > like library format, SDL and xvimage hardware support. It would be great if > > the patches would make it back into the CVS mainstream. > > I'm working on it right now. > > > I made a few changes to libdv too: the code now compiles both with gcc and > > g++. Basically it was changing a few names like "class" and "private" and > > some array initializers. I am not sure whether this is useful for anybody > > else; I did this because I wanted to use the libdv code in a C++ program > > and that was before the library patch was available. > > > Arne > > Could you submit a patch for this? I'll integrate it with the other > things. > > I will be doing a CVS commit for the existing patches today. I think your (buck's) previous "greeen ring" correction breaks my xvimage patch. I made a corrected version and I'll send it to Buck soon. > > -- Buck > _______________________________________________ > libdv-dev mailing list > lib...@li... > http://lists.sourceforge.net/mailman/listinfo/libdv-dev -- mfg Stefan Lucke (lu...@sn...) |
|
From: Charles 'B. K. <kr...@ac...> - 2000-11-12 19:37:07
|
Arne Schirmacher <ar...@sc...> writes: > There are several patches in the libdv repository on sourceforge. Features > like library format, SDL and xvimage hardware support. It would be great if > the patches would make it back into the CVS mainstream. I'm working on it right now. > I made a few changes to libdv too: the code now compiles both with gcc and > g++. Basically it was changing a few names like "class" and "private" and > some array initializers. I am not sure whether this is useful for anybody > else; I did this because I wanted to use the libdv code in a C++ program > and that was before the library patch was available. > Arne Could you submit a patch for this? I'll integrate it with the other things. I will be doing a CVS commit for the existing patches today. -- Buck |
|
From: Arne S. <ar...@sc...> - 2000-11-12 18:58:38
|
(sorry for my last post, I entered the wrong email address) There are several patches in the libdv repository on sourceforge. Features like library format, SDL and xvimage hardware support. It would be great if the patches would make it back into the CVS mainstream. I made a few changes to libdv too: the code now compiles both with gcc and g++. Basically it was changing a few names like "class" and "private" and some array initializers. I am not sure whether this is useful for anybody else; I did this because I wanted to use the libdv code in a C++ program and that was before the library patch was available. Arne |
|
From: Arne S. <ar...@sc...> - 2000-11-11 10:54:25
|
Here's the testcase:
#!/bin/ksh
while [ true ] ; do
dvgrab --frames 25 testfile
done
Ok, this is a nasty testcase, but I'm a professional software tester and
this is what I do to software all day long... and even worse things... :-)
This fails with both the Aug. 21 download and the Oct. 24 download from
ieee1394 CVS after a few loops. Sometimes immediately, sometimes after many
loops (like 50).
The major difference is: with the Aug. 21 version I can recover by killing
dvgrab and unloading and reloading the ieee1394 drivers. The testcase would
then run again for a number of loops.
With the Oct. 24 version my system either locks up completely (I need to
press reset), or the ieee1394 driver won't unload, forcing me to reboot
too. I noticed also that with this version dvgrab usually does not work the
first time (it just sits there idle), I have to press ctrl-c and the start
it again.
Any comments?
|
|
From: Charles 'B. K. <kr...@ac...> - 2000-11-10 23:19:55
|
Yep. Nice spot! It's in CVS now. -- Buck |
|
From: Charles 'B. K. <kr...@ac...> - 2000-11-10 19:40:08
|
Ok. I found the source of the "green ring" problem and committed the fix to CVS. The output of the YUV->RGB equations is in the range -255 .. 512, where the clamping to 0 .. 255 was only expecting -128 .. 383. Doh! -- Buck |
|
From: Stefan L. <lu...@sn...> - 2000-11-10 19:10:07
|
Hi,
9 bit signed value range is -256 .. 255,
so unsigned value 256 translates to -256 and 511 to 255
C code should be corrected by:
----- cut -----
--- parse.c.orig Fri Nov 10 00:46:39 2000
+++ parse.c Fri Nov 10 15:51:41 2000
@@ -478,5 +478,5 @@
memset(bl->coeffs, 0, sizeof(bl->coeffs));
dc = bitstream_get(bs,9); // DC coefficient (twos complement)
- if(dc > 256) dc -= 513;
+ if(dc > 255) dc -= 512;
bl->coeffs[0] = dc;
vlc_trace("DC [%d,%d,%d,%d] = %d\n",mb->i,mb->j,mb->k,b,dc);
@@ -493,5 +493,5 @@
// Get DC coeff, mode, and class from start of block
dc = bitstream_get(bs,9); // DC coefficient (twos complement)
- if(dc > 256) dc -= 513;
+ if(dc > 255) dc -= 512;
bl->coeffs[0] = dc;
vlc_trace("DC [%d,%d,%d,%d] = %d\n",mb->i,mb->j,mb->k,b,dc);
----- cut -----
Assembly code of vlc_x86.S could be simplified by just
a word arithmetric shift right.
----- cut -----
--- vlc_x86.S.orig Sun Jul 16 12:49:39 2000
+++ vlc_x86.S Fri Nov 10 19:16:04 2000
@@ -454,14 +454,9 @@
orl %ecx,%eax
- movl %eax,%edx
- shrl $7,%edx /* dc in %edx */
-
- /* if(dc > 256) dc -= 513; */
- movl $257,%ecx
- subl %edx,%ecx
- sarl $31,%ecx
- andl $-513,%ecx
- addl %edx,%ecx
- movw %ecx,dv_block_t_coeffs(%ebp)
+ movl %ax,%dx
+ /* if(dc > 255) dc -= 512;
+ just do an arithmetric shift right 7bits*/
+ sar $7,%dx /* dc in %dx */
+ movw %dx,dv_block_t_coeffs(%ebp)
/* bl->class_no = bitstream_get(bs,2); */
----- cut -----
--
mfg
Stefan Lucke (lu...@sn...)
|
|
From: Charles 'B. K. <kr...@ac...> - 2000-11-10 00:04:27
|
For both problem.dv and problem3.dv, here's what I see:
libdv - green around light
libdv + SDL patch - green around light
libdv + Xv patch - OK
My machine has a rage 128, with XFree 4.0.1 + Xv patch from gatos CVS.
So, I must conclude that it's a clamping problem. I'll press on...
This is totally consistent with the visual nature of the artifact.
-- Buck
|
|
From: Arne S. <ar...@sc...> - 2000-11-09 21:48:07
|
I used libdv patched with xvimage patch, but I will check it with the SDL version too. However I am more of an end-user of libdv and quite clueless how the decoding actually works and where to look.... Arne -----Original Message----- From: Stefan Lucke Sent: Thursday, November 09, 2000 9:07 PM To: Libdv-Dev (E-Mail) Subject: RE: [libdv-dev] libdv bug? On Don, 09 Nov 2000, Arne Schirmacher wrote: > I tried the hardware version too, but there are still errors (green spots > every once in a while). Check out the file problem3.dv, where I isolated a > few frames. My card is a Matrox G200. I can't verify the green spots in this file. Did you used the SDL or the plain Xv version? My card is a Matrox G400DH (much faster AGP transfers than my previous G200 with my MB ASUS-P5A). > > Anyway, if the hardware version works better this suggests that the problem > is somewhere in the yuv to rgb conversion code. I don't thing that the source of the problem is YUV -> RGB conversion. The table lookup for Y values is sometimes fed with large negative values -133 .. (not true for your examples but for some of mine). Such negative values should not exist !! Regions affected by your example are produced by idct88 and idct248. So where to look for ? -- mfg Stefan Lucke (lu...@sn...) _______________________________________________ libdv-dev mailing list lib...@li... http://lists.sourceforge.net/mailman/listinfo/libdv-dev |
|
From: Stefan L. <lu...@sn...> - 2000-11-09 21:19:08
|
On Don, 09 Nov 2000, Arne Schirmacher wrote: > I tried the hardware version too, but there are still errors (green spots > every once in a while). Check out the file problem3.dv, where I isolated a > few frames. My card is a Matrox G200. I can't verify the green spots in this file. Did you used the SDL or the plain Xv version? My card is a Matrox G400DH (much faster AGP transfers than my previous G200 with my MB ASUS-P5A). > > Anyway, if the hardware version works better this suggests that the problem > is somewhere in the yuv to rgb conversion code. I don't thing that the source of the problem is YUV -> RGB conversion. The table lookup for Y values is sometimes fed with large negative values -133 .. (not true for your examples but for some of mine). Such negative values should not exist !! Regions affected by your example are produced by idct88 and idct248. So where to look for ? -- mfg Stefan Lucke (lu...@sn...) |
|
From: Erik W. <om...@cs...> - 2000-11-09 19:38:18
|
On Thu, 9 Nov 2000, Arne Schirmacher wrote:
> Do you think that there is a problem with GTK? I thought the green ring was
> already in the RGB buffer data.
Not in GTK, but the conversion code. If you've got YUV values that manage
to exceed the accepted values of white or black (since the Y range is
16-240, not 0-255), the math works out such that you get rather random
results. The most common problem is wraparound of the RGB values, so that
while the math returns a value of, say 260, you actually get 5. If you're
supposed to have white, suddenly losing one of the components gets you a
nice cyan, yellow, or magenta.
I've got significantly better MMX color conversion code that I'll be
putting in CVS (along with some other stuff, like actual lib-ification) in
the next few days. That should make things quite a bit better.
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: Arne S. <ar...@sc...> - 2000-11-09 19:24:53
|
I tried the hardware version too, but there are still errors (green spots every once in a while). Check out the file problem3.dv, where I isolated a few frames. My card is a Matrox G200. Anyway, if the hardware version works better this suggests that the problem is somewhere in the yuv to rgb conversion code. Do you think that there is a problem with GTK? I thought the green ring was already in the RGB buffer data. Arne -----Original Message----- From: Stefan Lucke Sent: Thursday, November 09, 2000 4:33 PM To: Arne Schirmacher; Libdv-Dev (E-Mail) Subject: Re: [libdv-dev] libdv bug? On Don, 09 Nov 2000, Arne Schirmacher wrote: > Please run this file with playdv (latest CVS version): > > http://www.schirmacher.de/tmp/problem.dv > > Note the green ring around the bright candle area. I tried it also with > older versions with the same results. I have a libdv version downloaded in > May 2000, where the error is not that bad, but still noticeable. > It?s reproducable for me, but ONLY only when I use the GTK displaying methods, but when I use the hardware accelerated Xv extensions (available as a patch) the green ring is NOT present. -- mfg Stefan Lucke (lu...@sn...) _______________________________________________ libdv-dev mailing list lib...@li... http://lists.sourceforge.net/mailman/listinfo/libdv-dev |
|
From: Charles 'B. K. <kr...@ac...> - 2000-11-09 17:58:17
|
That was my first suspicion, but I didn't get a chance to test it. Clearly it's a bug in the "clamping" code to deal with out of range values (super-whites and blacks). -- Buck Stefan Lucke <lu...@sn...> writes: > On Don, 09 Nov 2000, Arne Schirmacher wrote: > > Please run this file with playdv (latest CVS version): > > > > http://www.schirmacher.de/tmp/problem.dv > > > > Note the green ring around the bright candle area. I tried it also with > > older versions with the same results. I have a libdv version downloaded in > > May 2000, where the error is not that bad, but still noticeable. > > > > It´s reproducable for me, but ONLY only when I use the GTK displaying methods, > but when I use the hardware accelerated Xv extensions (available as a patch) > the green ring is NOT present. > > -- > > mfg > > Stefan Lucke (lu...@sn...) > _______________________________________________ > libdv-dev mailing list > lib...@li... > http://lists.sourceforge.net/mailman/listinfo/libdv-dev |
|
From: Stefan L. <lu...@sn...> - 2000-11-09 16:38:45
|
On Don, 09 Nov 2000, Arne Schirmacher wrote: > Please run this file with playdv (latest CVS version): > > http://www.schirmacher.de/tmp/problem.dv > > Note the green ring around the bright candle area. I tried it also with > older versions with the same results. I have a libdv version downloaded in > May 2000, where the error is not that bad, but still noticeable. > It´s reproducable for me, but ONLY only when I use the GTK displaying methods, but when I use the hardware accelerated Xv extensions (available as a patch) the green ring is NOT present. -- mfg Stefan Lucke (lu...@sn...) |
|
From: Arne S. <ar...@sc...> - 2000-11-09 08:07:45
|
Another version of my AVI editor program is available. It now contains an almost complete set of vi-commands for navigating and cut/copy/paste operations plus menu commands equivalents for the most important keyboard commands. http://www.schirmacher.de/arne/kino/kino_0.2.tar.gz http://sourceforge.net/projects/kino/ If anybody would like to join the development team, please send me an email. Arne |
|
From: Arne S. <ar...@sc...> - 2000-11-09 08:07:24
|
Please run this file with playdv (latest CVS version): http://www.schirmacher.de/tmp/problem.dv Note the green ring around the bright candle area. I tried it also with older versions with the same results. I have a libdv version downloaded in May 2000, where the error is not that bad, but still noticeable. Arne |
16 messages has been excluded from this view by a project administrator.
