libdv-dev

[libdv-dev] Credits

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

My Kino program contains the libdv code, which form of credits should I 
include? Quasar Codec? Or the names of the programmers? What is the 
complete list?

As an aside, I tried a recent libdv snapshot with hardware support and I 
got 45 fps. Cool. Now I need it to slow it down somehow.....

Arne

Re: [libdv-dev] 16:9 / wide screen indicator

[Lukas K. <lu...@ra...>]

Erik Walthinsen wrote:
> 
> > I'm going comparision-shopping at some big electronics stores this
> > weekend, and I'm bringing some DV tapes to get evidence :)
> 
> That's not such a bad idea.  I'll see if they'll let me do that at
> CameraWorld.  Then I can try to get it dumped down to DV and put online, a
> few frames of each camera, try to get the same framing and so on.

One thing that can really make a consumer DV camera suck is a cheap wide
angle lens. My Sony PC100 has a nice Carl Zeiss lens and I stick a $30
dollar wide angle cheap glass thing on it and I am pretty sure I lose
about half of the resolving power around the 10% of the frame thats
around the edges. Some of the Kenko lenses are even worse. The chromatic
aberration can be really bad.

Does anybody have a URL's for good wide angle lenses for the PC100 ?

/Lukas

PS If you are bored you can see the result of some Win32 DV editing at
http://zelda.spray.se/~lukas/video.jsp .

Re: [libdv-dev] 16:9 / wide screen indicator

[Erik W. <om...@cs...>]

> I'm going comparision-shopping at some big electronics stores this
> weekend, and I'm bringing some DV tapes to get evidence :) 

That's not such a bad idea.  I'll see if they'll let me do that at
CameraWorld.  Then I can try to get it dumped down to DV and put online, a
few frames of each camera, try to get the same framing and so on.

         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

Re: [libdv-dev] Re: API Change / slowdown !

[Stefan L. <lu...@sn...>]

On Don, 23 Nov 2000, Charles 'Buck' Krasic wrote:
> Hmm.  
> 
> Some of my changes could effect performance, mainly due to cache
> footprint issues.
> 
> However, I just tried a similar test and got only a very slight
> difference.  (~0.15s for 150 frames).  (I used -D 2000-11-20).
> 
> Did you run your test several times to ensure warm filesystem caches?
Yes, previous values where for a PAL sequence.
Now I tried it with pond.dv.
old time playdv:
 180 frames displayed

real    0m11.663s
user    0m9.760s
sys     0m0.310s

new time playdv:
Displayed 180 frames in 14.2 seconds

real    0m14.334s
user    0m12.490s
sys     0m0.130s   

My systems is a AMD K6/2 400 128 MB RAM
Matrox G400
kernel 2.4.0-test10
plain X11 V4.0.1

disk speed:
jarada:~ # hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   64 MB in  1.09 seconds =58.72 MB/sec
 Timing buffered disk reads:  32 MB in  1.98 seconds =16.16 MB/sec    


> Stefan Lucke <lu...@sn...> writes:
> 
> > Hi Buck,
> 
> > I just compared lastest version (with if (Success == Xv ....))
> > with a version checked out with option -D 2000-11-20 (without API change
> > but YUY2.c changes).
> 
> > Runtime difference is about 2.7 seconds in user mode for a 150 picture
> > sequence (for 10 seconds to 13 seconds). I used '-mcpu=i686 -s -O6' as
> > compile options.
> 
> > old time playdv:
> > real    0m13.189s
> > user    0m10.690s
> > sys     0m0.410s
> 
> > new time playdv:
> > real    0m15.769s
> > user    0m13.310s
> > sys     0m0.210s
> 
-- 

mfg

  Stefan Lucke (lu...@sn...)

Re: [libdv-dev] can't play pond.dv with XVideo now

[Stefan L. <lu...@sn...>]

On Don, 23 Nov 2000, you wrote:
> Stefan Lucke wrote:
> > 
> > On Mit, 22 Nov 2000, Charles 'Buck' Krasic wrote:
> > > I think I've fixed the bug, and I just put it into CVS.
> > >
> > > Could you test for me?
> 
> Yep, did a cvs update, make , ./playdv pond.dv and it worked fine.
> [lukas@sto-lknutsson libdv]$ ./playdv pond.dv 
> Xlib:  extension "XVideo" missing on display ":0.0".
> Xlib:  extension "XVideo" missing on display ":0.0".
>  Using gtk for display
> Displayed 915 frames in 125.0 seconds
> 
> Pretty slow. Then I did the change to my XF86Config. I had no modules
> section, but after reading the man page and looking I found that I had

It is quiet unusual that there is no modules section. With X11 4x this file
could be placed some where else. Perhaps in directory /etc/X11/ .
So search for this file or have a look at the X11 log file placed in ? 
For my system it is in /var/log and it's name is XFree86.0.log.

> libextmod.a in /usr/X11R6/lib/modules/extensions/. So I added this to
> XF86Config,
> 
> Section "Module"
>    Load "extmod"
> EndSection
> 
-- 

mfg

  Stefan Lucke (lu...@sn...)

[libdv-dev] can't play pond.dv with XVideo now

[Lukas K. <lu...@ra...>]

Stefan Lucke wrote:
> 
> On Mit, 22 Nov 2000, Charles 'Buck' Krasic wrote:
> > I think I've fixed the bug, and I just put it into CVS.
> >
> > Could you test for me?

Yep, did a cvs update, make , ./playdv pond.dv and it worked fine.
[lukas@sto-lknutsson libdv]$ ./playdv pond.dv 
Xlib:  extension "XVideo" missing on display ":0.0".
Xlib:  extension "XVideo" missing on display ":0.0".
 Using gtk for display
Displayed 915 frames in 125.0 seconds

Pretty slow. Then I did the change to my XF86Config. I had no modules
section, but after reading the man page and looking I found that I had
libextmod.a in /usr/X11R6/lib/modules/extensions/. So I added this to
XF86Config,

Section "Module"
   Load "extmod"
EndSection

But then running ./playdv pond.dv got this message.
[lukas@sto-lknutsson libdv]$ ./playdv pond.dv &
[1] 1006
[lukas@sto-lknutsson libdv]$ Xlib:  extension "XVideo" missing on
display ":0.0".
Xlib:  extension "XVideo" missing on display ":0.0".
 
It doesn't seem that the extmod extension did anything. How can I test
if it actually loaded ?

> >
> > If it doesn't work, you should be able to turn off Xv support, set
> > HAVE_XV40x=0, in the Makefile.
> Fix is OK message is now (if extmod is not loaded/defined):

Hmm, but I am trying to load extmod now ? Hmm, need more advice please.
I have a Matrox Millenium G200 AGP.

/Lukas

[libdv-dev] Re: API Change / slowdown !

[Charles 'B. K. <kr...@ac...>]

Hmm.  

Some of my changes could effect performance, mainly due to cache
footprint issues.

However, I just tried a similar test and got only a very slight
difference.  (~0.15s for 150 frames).  (I used -D 2000-11-20).

Did you run your test several times to ensure warm filesystem caches?

-- Buck

Stefan Lucke <lu...@sn...> writes:

> Hi Buck,

> I just compared lastest version (with if (Success == Xv ....))
> with a version checked out with option -D 2000-11-20 (without API change
> but YUY2.c changes).

> Runtime difference is about 2.7 seconds in user mode for a 150 picture
> sequence (for 10 seconds to 13 seconds). I used '-mcpu=i686 -s -O6' as
> compile options.

> old time playdv:
> real    0m13.189s
> user    0m10.690s
> sys     0m0.410s

> new time playdv:
> real    0m15.769s
> user    0m13.310s
> sys     0m0.210s

> -- 
> 
> mfg
> 
>   Stefan Lucke (lu...@sn...)

Re: [libdv-dev] could not play pond.dv

[Stefan L. <lu...@sn...>]

On Mit, 22 Nov 2000, Charles 'Buck' Krasic wrote:
> I think I've fixed the bug, and I just put it into CVS.
> 
> Could you test for me?  
> 
> If it doesn't work, you should be able to turn off Xv support, set
> HAVE_XV40x=0, in the Makefile.
Fix is OK message is now (if extmod is not loaded/defined):

Xlib:  extension "XVideo" missing on display ":0.0".
 Using gtk for display    

That means that either the hardware does not support Xv extension
or Lukas has to adjust his /etc/XF86Config to the following:

Section "Module"
  Load          "drm"
  Load          "glx"
  Load          "type1"
  Load          "dbe"
  Load          "freetype"
  Load          "dri"
  Load         "extmod"   # <---- !!!!
EndSection  


> 
> -- Buck
> 
> Lukas Knutsson <lu...@ra...> writes:
> 
> > updated libdv from CVS today and built it (no probs).
> 
> > [lukas@sto-lknutsson libdv]$ ./playdv pond.dv &
> > [1] 9796
> > [lukas@sto-lknutsson libdv]$ Xlib:  extension "XVideo" missing on
> > display ":0.0".
> > Xv: (null): ports 0 - -1
> 
> > [1]+  Segmentation fault      (core dumped) ./playdv pond.dv
> 
> > Bummer. I am running RedHat 7.0, with XFree 4.0.1. What can I do to get
> > this running, or do I need to comment out some stuff in the Makefile.
> 
> > /Lukas
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> http://lists.sourceforge.net/mailman/listinfo/libdv-dev
-- 

mfg

  Stefan Lucke (lu...@sn...)

[libdv-dev] API Change / slowdown !

[Stefan L. <lu...@sn...>]

Hi Buck,

I just compared lastest version (with if (Success == Xv ....))
with a version checked out with option -D 2000-11-20 (without API change
but YUY2.c changes).

Runtime difference is about 2.7 seconds in user mode for a 150 picture
sequence (for 10 seconds to 13 seconds). I used '-mcpu=i686 -s -O6' as
compile options.

old time playdv:
real    0m13.189s
user    0m10.690s
sys     0m0.410s

new time playdv:
real    0m15.769s
user    0m13.310s
sys     0m0.210s

-- 

mfg

  Stefan Lucke (lu...@sn...)

Re: [libdv-dev] could not play pond.dv

[Charles 'B. K. <kr...@ac...>]

I think I've fixed the bug, and I just put it into CVS.

Could you test for me?  

If it doesn't work, you should be able to turn off Xv support, set
HAVE_XV40x=0, in the Makefile.

-- Buck

Lukas Knutsson <lu...@ra...> writes:

> updated libdv from CVS today and built it (no probs).

> [lukas@sto-lknutsson libdv]$ ./playdv pond.dv &
> [1] 9796
> [lukas@sto-lknutsson libdv]$ Xlib:  extension "XVideo" missing on
> display ":0.0".
> Xv: (null): ports 0 - -1

> [1]+  Segmentation fault      (core dumped) ./playdv pond.dv

> Bummer. I am running RedHat 7.0, with XFree 4.0.1. What can I do to get
> this running, or do I need to comment out some stuff in the Makefile.

> /Lukas

Re: [libdv-dev] Lib status of libdv.

[Charles 'B. K. <kr...@ac...>]

Doh.  Fixups are in CVS now.

-- Buck

"Scott F. Johnston" <sc...@fl...> writes:

> Hello,

> The lib seems to be coming together!

> One thing-- try to compile with SDL and XV off for software only
> decoding,
> and you'll notice some problems.
> In display.h, you have several "#ifdef HAVE_SDL"
> These are ALWAYS being included, since the tokens are defined, they
> are just SET to 0 rather than set to 1. You want "#if" rather than
> "#ifdef".

> (Most likely you've got SDL and XV, so even when you try to compile with
> these flags set to 0, you're finding the various includes, etc.)

> --Scott

[libdv-dev] could not play pond.dv

[Lukas K. <lu...@ra...>]

updated libdv from CVS today and built it (no probs).

[lukas@sto-lknutsson libdv]$ ./playdv pond.dv &
[1] 9796
[lukas@sto-lknutsson libdv]$ Xlib:  extension "XVideo" missing on
display ":0.0".
Xv: (null): ports 0 - -1

[1]+  Segmentation fault      (core dumped) ./playdv pond.dv

Bummer. I am running RedHat 7.0, with XFree 4.0.1. What can I do to get
this running, or do I need to comment out some stuff in the Makefile.

/Lukas

Re: [libdv-dev] Problems compiling encode.c

[Charles 'B. K. <kr...@ac...>]

I've made a lot of changes recently, ignoring encode.c--my bad.  

I'm going to revisit the TODO list now, and encode.c will
be high priority.

-- Buck

Lukas Knutsson <lu...@ra...> writes:

> I upgraded sdl to 1.1.6 and can build libdv but cannot compile
> encode.c.  Amongst small function definition problems (ie memset not
> defined etc) I hit this error,

> encode.c:571: too few arguments to function `dv_place_411_macroblock'

> That function is actually defined as such.  place.h:extern void
> dv_place_411_macroblock(dv_macroblock_t *mb, gint *x, gint *y);

> But the method is called from encode by passing an int instead of 2
> gint*'s.

> It looks like encode.c is a bit broken. Anybody working on it ?

> /Lukas

Re: [libdv-dev] Lib status of libdv.

[Charles 'B. K. <kr...@ac...>]

Hi Daniel,

I'm sorry for not responding to your message sooner.  I thought I was
almost done with some changes to the API.  Now after several days, I
finally finished them off and put them in libdv CVS.

I think we're reasonably close to something that might be packaged.

I use RedHat, some I'm not able to help with .debs.  I'm not aware of
anybody else doing it.

Building as a shared lib shouldn't be a big deal.  I'd had a bad
experience with the autotools around the time we started libdv, so I
decided to stick with plain Makefile.  It probably wouldn't be a big
deal to convert to autotools.

-- Buck

Daniel Kobras <ko...@ta...> writes:

> Hi!

> I've seen libdv now really builds as a static lib. Cool. I'm
> currently looking into packaging some programs for the Debian
> distribution that depend on libdv. My preferred option therefore
> would be to build a libdv package as well. However I'd like to have
> a word from the developers if you consider this sensible by now?
> Would you consider the API reasonably stable? How about building as
> a shared lib? Or is someone else by chance already working on libdv
> .debs? I'd be happy if you could drop me a note.

> Thanks,

> Daniel.

[libdv-dev] Problems compiling encode.c

[Lukas K. <lu...@ra...>]

I upgraded sdl to 1.1.6 and can build libdv but cannot compile encode.c.
Amongst small function definition problems (ie memset not defined etc) I
hit this error,

encode.c:571: too few arguments to function `dv_place_411_macroblock'

That function is actually defined as such.
place.h:extern void dv_place_411_macroblock(dv_macroblock_t *mb, gint
*x, gint *y);

But the method is called from encode by passing an int instead of 2
gint*'s.

It looks like encode.c is a bit broken. Anybody working on it ?

/Lukas

RE: [libdv-dev] Problems compiling libdv

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

I had compile problems too, I solved this by downloading the latest SDL 
version and changing one or two variable names in the libdv code. I can't 
remember any details anymore, but it was straightforward to fix.

stdio input outut would be neat. I'll change the next version of dvgrab to 
support this too for raw dv data. For now maybe you can get it working by 
using a named pipe (I did not try this though):

mknod fifo p
cat fifo | your_prog &
dvgrab --format raw fifo


Arne

-----Original Message-----
From:	Lukas Knutsson
Sent:	Friday, November 17, 2000 1:11 PM
To:	lib...@li...
Subject:	[libdv-dev] Problems compiling libdv

Hi,

I'm now getting off my butt to help with libdv.

I checked out libdv from CVS and could not compile it on my RedHat 7
system.

cc -mcpu=i686 -g -O -fstrict-aliasing -Wall  -I. -I/usr/lib/glib/include
-I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/SDL
-D_REENTRANT -DUSE_MMX_ASM=1 -DHAVE_XV40x=1 -DHAVE_GTK=1 -DHAVE_SDL=1
-I. -I/usr/lib/glib/include -I/usr/lib/glib/include -I/usr/X11R6/include
-I/usr/include/SDL -D_REENTRANT -DUSE_MMX_ASM=1 -DHAVE_XV40x=1
-DHAVE_GTK=1 -DHAVE_SDL=1  -c -o display.o display.c

display.c: In function `dv_display_SDL_init':
display.c:347: structure has no member named `hw_overlay'

I noticed this function dv_display_SDL_init has 2 versions depending on
whether #if HAVE_SDL is defined or not.

hw_overlay appears to be a member of overlay which is of type
SDL_Overlay . Looking in /usr/include/SDL/SDL_video.h I see this,

/* The YUV hardware video overlay */
typedef struct SDL_Overlay {
	Uint32 format;				/* Read-only */
	int w, h;				/* Read-only */
	Uint16 pitch;				/* Read-only */
	void *pixels;				/* Read-write */

	/* Hardware-specific surface info */
	struct private_yuvhwfuncs *hwfuncs;
	struct private_yuvhwdata *hwdata;
} SDL_Overlay;

So what gives ? DO I have some out of date stuff or is the current CVS
version temporarily broken or is RedHat 7 causing problems.

/Lukas (would really like to get encode working. Especially to use like
a filter in a pipe chain ppmcoolimageproducer | encode > lukas.dv. Will
hack encode so it can read from stdin if it doesn't already do it.)
_______________________________________________
libdv-dev mailing list
lib...@li...
http://lists.sourceforge.net/mailman/listinfo/libdv-dev

[libdv-dev] Interlacing

[Lukas K. <lu...@ra...>]

I noticed in my Windows DV editing app that when I create a video from
stills they never seem quite as smooth as I thought they would. If I
plan to make POV ray output PPM images, in what way should I interlace
the images to get best smoothest movement before I encode them to DV
using encode.c ?

Instead of 25 static scenes representing action at 0.04 sec intervals, I
plan to divide the action up into 0.02 sec intervals and have POV ray
generate lines 0,2,4,...,718 from scene 0.0 and lines 1,3,5,....,719
from scene 0.02 etc, then make the next frame from 

Will this display correctly ?

/Lukas

[libdv-dev] Problems compiling libdv

[Lukas K. <lu...@ra...>]

Hi,

I'm now getting off my butt to help with libdv.

I checked out libdv from CVS and could not compile it on my RedHat 7
system.

cc -mcpu=i686 -g -O -fstrict-aliasing -Wall  -I. -I/usr/lib/glib/include
-I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/SDL
-D_REENTRANT -DUSE_MMX_ASM=1 -DHAVE_XV40x=1 -DHAVE_GTK=1 -DHAVE_SDL=1 
-I. -I/usr/lib/glib/include -I/usr/lib/glib/include -I/usr/X11R6/include
-I/usr/include/SDL -D_REENTRANT -DUSE_MMX_ASM=1 -DHAVE_XV40x=1
-DHAVE_GTK=1 -DHAVE_SDL=1  -c -o display.o display.c

display.c: In function `dv_display_SDL_init':
display.c:347: structure has no member named `hw_overlay'

I noticed this function dv_display_SDL_init has 2 versions depending on
whether #if HAVE_SDL is defined or not.

hw_overlay appears to be a member of overlay which is of type
SDL_Overlay . Looking in /usr/include/SDL/SDL_video.h I see this,

/* The YUV hardware video overlay */
typedef struct SDL_Overlay {
	Uint32 format;				/* Read-only */
	int w, h;				/* Read-only */
	Uint16 pitch;				/* Read-only */
	void *pixels;				/* Read-write */

	/* Hardware-specific surface info */
	struct private_yuvhwfuncs *hwfuncs;
	struct private_yuvhwdata *hwdata;
} SDL_Overlay;

So what gives ? DO I have some out of date stuff or is the current CVS
version temporarily broken or is RedHat 7 causing problems.

/Lukas (would really like to get encode working. Especially to use like
a filter in a pipe chain ppmcoolimageproducer | encode > lukas.dv. Will
hack encode so it can read from stdin if it doesn't already do it.)

[libdv-dev] Aspect ratio (Was: Quality)

[Stefan L. <lu...@sn...>]

Arne Schirmacher <ar...@sc...> writes:

> What about half or quarter size image areas? The 720 * 576 player
> area in Kino is way too big anyway. Many Windows programs use only
> half the size.
Even though 720x576 (PAL) is not enough. It should be 768x576 for 4:3
and 1024x576 for 16:9 recorded video. Viewing 720x576 on a 4:3
(physical screen) with a display resolution of 1152x864, which is 4:3
too, every thing looks a bit too tall.
Viewing sizes for NTSC should be 640x480 (4:3) and 768x480 (16:10) or
854x480 (16:9). Can anyone confirm these wide screen NTSC values ?

-- 

mfg

  Stefan Lucke (lu...@sn...)

Re: [libdv-dev] Quality

[Charles 'B. K. <kr...@ac...>]

Arne Schirmacher <ar...@sc...> writes:

> Applications using libdv, such as my Kino program, would need both
> speed and best quality (not necessarily at the same time though).

Agreed.

> During editing the user want speed and during conversion to other
> formats the user wants best quality images as an input, so this
> should be user defineable in my opinion (a parameter).

Agreed.

> I'm not even close to conversion things with Kino right now, so
> currently I'm most interested in speed. I tried the quality
> parameter in playdv.c a while ago but it did not improve the speed
> more than some ten percent (I was expecting powers of ten :-).

I just did a quick check and I see much more than 10% speedups.
For setting DV_QUALITY_AC_1, I see about %30 reduction.  Setting
DV_QUALITY_DC gives about %50.

> What about half or quarter size image areas? The 720 * 576 player
> area in Kino is way too big anyway. Many Windows programs use only
> half the size.

I'll add this to the TODO list.   Given the numbers above, I'd guess
an overall speedup on the order of 40%.

Another option is 90x{60|72}, based on the DC only setting.  This would
probably require %30 of realtime.

> Arne

-- Buck

RE: [libdv-dev] IDCT-248 mmx

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

Here's the error message. I am not an MMX assembly expert but the reason 
seems to be that certain macros are expanded such that the result has 
spaces in it, which can't be handled by the assembler.

Arne



-----Original Message-----
From:	Stefan Lucke
Sent:	Tuesday, November 14, 2000 8:49 PM
To:	Arne Schirmacher; lib...@li...
Subject:	RE: [libdv-dev] IDCT-248 mmx

>
> 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...)

RE: [libdv-dev] Re: [libdv - Open Discussion] Quality

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

Applications using libdv, such as my Kino program, would need both speed 
and best quality (not necessarily at the same time though).

During editing the user want speed and during conversion to other formats 
the user wants best quality images as an input, so this should be user 
defineable in my opinion (a parameter).

I'm not even close to conversion things with Kino right now, so currently 
I'm most interested in speed. I tried the quality parameter in playdv.c a 
while ago but it did not improve the speed more than some ten percent (I 
was expecting powers of ten :-).

What about half or quarter size image areas? The 720 * 576 player area in 
Kino is way too big anyway. Many Windows programs use only half the size.

Arne

-----Original Message-----
From:	Charles 'Buck' Krasic
Sent:	Wednesday, November 15, 2000 9:54 PM
To:	rb...@us...
Cc:	lib...@li...
Subject:	[libdv-dev] Re: [libdv - Open Discussion] Quality


In the libdv - Open Discussion form, rb...@us... writes:

> Firsts off, hats off to you folks for the endevour, I have been
> waiting for something like this lib for a long time.

> I am looking to get super high quality frames from a DV stream and
> the playback speed is not important. I started to play around with
> some of the settings, but have been unsuccessful so far (a little
> rusty on my DCTs).

> Is is possible to get the image quality up to par with a hardware
> decoder with libdv? Is so, how could this be accomplished?

First, are you using a current version of libdv from CVS?

There were some major bugs fixed recently that have significant impact
on quality.  If yes, and it's _really_ high quality you want, read on...

If you don't care about speed at all, the easy way is to turn off
assembly and MMX.  Set USE_MMX_ASM=0 in the Makefile.  It will be
run about 10x slower, but you should get full quality.  Except
perhaps, for the color conversion.

>From there, we have two major issues to discuss:

  A) How do we build diagnostic harness that allows us to measure
     the quality of our results?

  B) What are the sources of quality loss?

I won't go into A just yet.  For B, here are some thoughts off the top
of my head:

1) DCT.  The MMX version we are using is imprecise.  Intel published
   an app-note on how to do better (i.e. meet IEEE DCT tolerance), and
   GPL versions of the newer, more precise, DCT have appeared in
   source code distributions for VirtualDub and Flask.  We should be
   able to integrate these quite easily.

   The 248 IDCT appears to be unique to DV, and so I coded that
   myself.  At the moment, I don't believe there is a quality
   sacrifice there, as it is still quite slow.  But it needs to
   be verified.

2) Weighting.  With ASM enabled, libdv merges the DV un-weighting
   with the first stage of the DCT calculation.  This saves
   computation, but sacrifices precision.

3) Color conversion (YV12.c, YUY2.c, rgb.c).  Except for the case of
   IEC PAL DV (4:2:0 sampled), we have to do some kind of color
   conversion before display.  Our code generally favours speed over
   accuracy.  The difference occurs when a target value is logically
   derived from some combination of source values.  Our code generally
   takes the approach of using one of the source values directly.  For
   example, if a target color value is logically defined ocr = 1/4
   icr0 + 3/4 icr1, our code does ocr = icr1.

Now, how much do these things affect quality.  To really know, we need
to address A.

-- Buck

ps I've moved this discussion from the forum to the mailing list.  I'm
   thinking about removing the libdv forums actually, as they are low
   traffic, and pretty redundent given the mailing list.















> many thanks,
> Roman

_______________________________________________
libdv-dev mailing list
lib...@li...
http://lists.sourceforge.net/mailman/listinfo/libdv-dev

[libdv-dev] Lib status of libdv.

[Daniel K. <ko...@ta...>]

Hi!

I've seen libdv now really builds as a static lib. Cool. I'm currently
looking into packaging some programs for the Debian distribution that
depend on libdv. My preferred option therefore would be to build a libdv
package as well. However I'd like to have a word from the developers if
you consider this sensible by now? Would you consider the API reasonably
stable? How about building as a shared lib? Or is someone else by chance
already working on libdv .debs? I'd be happy if you could drop me a note.

Thanks,

Daniel.

-- 
	GNU/Linux Audio Mechanics - http://www.glame.de
              Cutting Edge Office - http://www.c10a02.de
	      GPG Key ID 89BF7E2B - http://www.keyserver.net

[libdv-dev] [Bug #122548] YUV 4:2:0 blocks corrupted

[<no...@so...>]

Bug #122548, was updated on 2000-Nov-15 18:56
Here is a current snapshot of the bug.

Project: Quasar DV Codec
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: YUV 4:2:0 blocks corrupted

Details: The cr and cb components are transposed in the 4:2:0 blocks.  Notice in this frame how the red L and I  get corrupted in the 4:2:0 blocks but not in the 4:1:1 blocks.  The same problem occurs in the pond.dv file but is barely noticable because everything is brown and dead in Oregon.

<IMG SRC="http://heroinewarrior.com/dv_bug.jpg">

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=122548&group_id=4393

[libdv-dev] Re: [libdv - Open Discussion] Quality

[Charles 'B. K. <kr...@ac...>]

In the libdv - Open Discussion form, rb...@us... writes:

> Firsts off, hats off to you folks for the endevour, I have been
> waiting for something like this lib for a long time.

> I am looking to get super high quality frames from a DV stream and
> the playback speed is not important. I started to play around with
> some of the settings, but have been unsuccessful so far (a little
> rusty on my DCTs).

> Is is possible to get the image quality up to par with a hardware
> decoder with libdv? Is so, how could this be accomplished?

First, are you using a current version of libdv from CVS?  

There were some major bugs fixed recently that have significant impact
on quality.  If yes, and it's _really_ high quality you want, read on...

If you don't care about speed at all, the easy way is to turn off 
assembly and MMX.  Set USE_MMX_ASM=0 in the Makefile.  It will be
run about 10x slower, but you should get full quality.  Except 
perhaps, for the color conversion.

From there, we have two major issues to discuss:

  A) How do we build diagnostic harness that allows us to measure
     the quality of our results?

  B) What are the sources of quality loss?

I won't go into A just yet.  For B, here are some thoughts off the top
of my head:

1) DCT.  The MMX version we are using is imprecise.  Intel published
   an app-note on how to do better (i.e. meet IEEE DCT tolerance), and
   GPL versions of the newer, more precise, DCT have appeared in
   source code distributions for VirtualDub and Flask.  We should be
   able to integrate these quite easily.

   The 248 IDCT appears to be unique to DV, and so I coded that
   myself.  At the moment, I don't believe there is a quality
   sacrifice there, as it is still quite slow.  But it needs to
   be verified.

2) Weighting.  With ASM enabled, libdv merges the DV un-weighting 
   with the first stage of the DCT calculation.  This saves
   computation, but sacrifices precision.

3) Color conversion (YV12.c, YUY2.c, rgb.c).  Except for the case of 
   IEC PAL DV (4:2:0 sampled), we have to do some kind of color
   conversion before display.  Our code generally favours speed over
   accuracy.  The difference occurs when a target value is logically
   derived from some combination of source values.  Our code generally
   takes the approach of using one of the source values directly.  For
   example, if a target color value is logically defined ocr = 1/4
   icr0 + 3/4 icr1, our code does ocr = icr1.

Now, how much do these things affect quality.  To really know, we need
to address A.

-- Buck

ps I've moved this discussion from the forum to the mailing list.  I'm 
   thinking about removing the libdv forums actually, as they are low
   traffic, and pretty redundent given the mailing list.








   






> many thanks,
> Roman