libdv-dev

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

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

[Replying to a really ancient mail.]

On Tue, Nov 21, 2000 at 01:37:22PM -0800, Charles 'Buck' Krasic wrote:
> 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.

I've tried to compile a sane Debian package of libdv for some time now,
and actually building libdv as a shared lib turns out to be quite a
problem, at least as far as the optimised versions are concerned. That's
because the asm routines are not coded to be relocatable. Changing this
basically involves sacrificing a register to the global offset table
and changing every reference to objects in the .data section when=20
__PIC__ is defined.

In detail, it appears that quant_x86.S transpose_x86.S are already fine
because they do not contain .data sections. dct_block_mmx.S, encode_x86.S,=
=20
idct_block_mmx.S appear to be trivially fixable, which leaves
rgbtoyuv.S and vlc_x86.S as the hard cases. Both make heavy uses of
registers and local data alike. Therefore, a straightforward approach
to code them relocatable might well affect performance in the static
case, too. The alternative being two completely seperate version for static=
=20
and shared linkage. What's your opinion on this? Do you consider it
worthwhile for libdv to be available as a shared lib at all?

Regards,

Daniel.

--=20
	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] RE: new Kino version and a small dv to jpeg utility available

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

Oops, forgot to actually upload the files, but they are available now.

Arne

-----Original Message-----
From:	Arne Schirmacher 
Sent:	Saturday, April 07, 2001 10:28 PM
To:	lib...@li...; lin...@li...
Subject:	new Kino version and a small dv to jpeg utility available

I fixed a compile problem of Kino with recent libdv releases. No other 
modifications were made due to lack of time.

I slapped together a small program for converting DV AVI files to series of 
jpeg images. This is only an example program for another developer, please 
do not expect too much from it (only twenty lines of new code).

See http://www.schirmacher.de/arne/kino/ for both programs.

Arne

_______________________________________________
mailing list lin...@li...
http://lists.sourceforge.net/lists/listinfo/linux1394-devel

Re: [libdv-dev] Attempting to port libdev to win32

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

I took a swing at it over the weekend, and got a basic version of playdv
to work on Windows 2000:  no audio, and only a slow C version.

I used cygwin, and the win32 port of glib/gtk, and I also built and
installed libtool.

The main changes I had to make were:

  1) hardcode glib/gtk include and link paths into the build since
     the win32 port doesn't have g*.m4 or g*-config

  2) copy timersub macro from /usr/include/sys/time.h on linux, since
     it doesn't exist on cygwin
 
  3) change code in playdv.c to not use mmap for file reading, mmap
     doesn't work in cygwin.  (I just replaced mmap with malloc/read, and
     munmap with free)

  4) Remove oss.c from the build, and disable all dv_oss_* calls in
     playdv.

  5) configure with --disable-asm.   Some of the libdv asm seems to
     use ELF specific directives which break on windows.

-- Buck

[libdv-dev] new Kino version and a small dv to jpeg utility available

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

I fixed a compile problem of Kino with recent libdv releases. No other 
modifications were made due to lack of time.

I slapped together a small program for converting DV AVI files to series of 
jpeg images. This is only an example program for another developer, please 
do not expect too much from it (only twenty lines of new code).

See http://www.schirmacher.de/arne/kino/ for both programs.

Arne

[libdv-dev] [ libdv-Patches-414436 ] real encoder improvements

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

Patches item #414436, was updated on 2001-04-06 15:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=414436&group_id=4393

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Peter Schlaile (schlaile)
Assigned to: Nobody/Anonymous (nobody)
Summary: real encoder improvements 

Initial Comment:
2001-04-07  Peter Schlaile <ud...@rz...>
        * VLC encoder improvements: static qno tables
for 3 passes
        * audio support for the encoder (plugin system
with wav and /dev/dsp
          support)
        * renamed build_coeff to fill_macroblock and
moved it into the
          input filter. Wrote specialized mmx copy
routines. 
          -> now we _are_ realtime on an Athlon 800
even with 3 VLC passes 
          (static qno tables!) It's time to throw the
video recorder away ;-)
        * New option: --fps : select frames per second
if your machine isn't
          fast enough for the full bandwidth
        * Interface changes: -t renamed to -v since it
gives additional
          verbose output now.
        * pgm support for mpeg2dec

2001-03-29  Peter Schlaile <ud...@rz...>
        * VLC encoder improvements: Now it's more
correct for 3 passes (but
          also slower...), faster for 2 passes.
Implemented turbo mode 
          (static qno tables). Hopefully makes the
thing finally realtime on 
          an Athlon 800...
        * Separated out the input and output queue.
Build general input and
          output filter plugin system. Included
/dev/video support.
        * several assembler optimized routines in the
vlc encoder added, 
          reorder_88 code is now merged with the DCT
postscaler to fill the 
          integer pipelines _and_ the MMX pipelines
        * renamed encode to encodedv
        * removed blur function since it doesn't make
sense
        * corrected (?) faster C version of
convert_to_yuv


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=414436&group_id=4393

Re: [libdv-dev] Attempting to port libdev to win32

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

John Carter <jn...@ec...> writes:

> I cured this when I realized that the on X86 implementation (the C
> code) was probably for a Sun or other such machine with a different
> byte order.

No.  Libdv's native home is x86 linux.  I use Redhat 7.0 myself.  I've
had some users report experiences porting to SGI/IRIX.

> So the parse.c was changed as follows

> #if !ARCH_X86
> #if WIN32
>      dv_reorder[DV_DCT_88][i] = ((dv_88_reorder_prime[i] / 8) * 8) +
>      (dv_88_reorder_prime[i] % 8);
> 
> #else
>      dv_reorder[DV_DCT_88][i] = ((dv_88_reorder_prime[i] % 8) * 8) +
>      (dv_88_reorder_prime[i] / 8);
> 
> #endif
> #else
>      dv_reorder[DV_DCT_88][i] = ((dv_88_reorder_prime[i] % 8) * 8) +
>      (dv_88_reorder_prime[i] / 8);
> 
> #endif

> going back to the byte order of an Intel machine.

Your change is definitely wrong.  The conditional in the code above
isn't about byte order.  It is about transposing the DCT coefficients
as part of re-ordering, because the mmx iDCT expects them that way.

> As I said, this cured the segmentation fault, and even produced
> pictures, but they were almost unrecognizable, similar to a
> television picture with a dubious horizontal sync, and lots of block
> errors.

> I've also attempted to recompile the assembly language version with
> the cygwin implementation of gcc, but have had to make many changes,
> and it currently blows up as it starts.


> Before I go any further I would appreciate some advice and
> information.

> Should the C code compiled on an Intel machine give the same results
> as the assembler version?

Umm, not exactly.  Some of the assembly routines are less precise than
their C counterparts, for example the idct.  Also, the C parsing code
is a little more robust.  In particular, the assembly version will
segfault on some faulty streams where the C version does not.


> If not, is it a byte order problem and could I have some pointers
> where to look.


> Is it possible to build a C version under linux so I can see exactly
> what is going on and what the differences are?

Yes.  

  ./configure --disable-asm


> Any other advice would be wonderful, unfortunately not doing this is
> not an option. I have the SMPTE standard and will probably start
> there next


> Thanks in advance,

> John Carter

I'm suprised how hard this is.  I may take a stab at it myself over
the weekend.

-- Buck

[libdv-dev] Re: libdv: dv format documentation link

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

I've added the link to the home page.  This is for sure the best free
document I've seen.

Thanks for the pointer!

-- Buck

"Arto Nirkko" <art...@in...> writes:

> Hi

> You may wish to include the following link to the dvcam format
> specification (detailed and well explained, both NTSC and PAL, seems
> more or less identical to dv) as pdf file from sony on your
> libdv.sourceforge.net homepage, so interested people may find it
> quicker, and without fee for the iec or smpte docs.
> 
> http://www.sony.ca/dvcam/dvcam%20format%20overview.pdf
> 
> Arto

[libdv-dev] libdv 0.7 released.

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

Version 0.7 is out. 

There are encoder improvements from Peter.  Also some compilation
fixups for non-x86 and non-Xv builds.

-- Buck

[libdv-dev] Attempting to port libdev to win32

[John C. <jn...@ec...>]

I suspect I'm mad but since I need to get at dv formatted video, in a 
vendor independent manner this seems a good place to start.

I'm using the 0.7 version, and have that working under SUSE  7.0 as a 
reference implementation.

To make  life easy (and to be sure I understand libdv) I have built a very 
simple application (called minidv) which reads a dv stream and  outputs the 
first n frames as .ppm files. This works as expected under linux.

After copying all the files to the windows environment. I've had the 
following success.

The first attempt a building the C files caused a segmentation fault, which 
I tracked down to some look up tables being indexed by large positive and 
negative numbers.

Both gcc and Visual C++(vcc) gave the same result.

I cured this when I realized that the on X86 implementation (the C code) 
was probably for a Sun or other such machine with a different byte order.

So the parse.c was changed as follows

#if !ARCH_X86
#if WIN32
     dv_reorder[DV_DCT_88][i] = ((dv_88_reorder_prime[i] / 8) * 8) + 
(dv_88_reorder_prime[i] % 8);
#else
     dv_reorder[DV_DCT_88][i] = ((dv_88_reorder_prime[i] % 8) * 8) + 
(dv_88_reorder_prime[i] / 8);
#endif
#else
     dv_reorder[DV_DCT_88][i] = ((dv_88_reorder_prime[i] % 8) * 8) + 
(dv_88_reorder_prime[i] / 8);
#endif

going back to the byte order of an Intel machine.

As I said, this cured the segmentation fault, and even produced pictures, 
but they were almost unrecognizable, similar to a television picture with a 
dubious horizontal sync, and lots of block errors.

I've also attempted to recompile the assembly language version with the 
cygwin implementation of gcc, but have had to make many changes, and it 
currently blows up as it starts.

Before I go any further I would appreciate some advice and information.

Should the C code compiled on an Intel machine give the same results as the 
assembler version?

If not, is it a byte order problem and could I have some pointers where to 
look.

Is it possible to build a C version under linux so I can see exactly what 
is going on and what the differences are?

Any other advice would be wonderful, unfortunately not doing this is not an 
option. I have the SMPTE standard and will probably start there next

Thanks in advance,

John Carter



Dr. John N. Carter   jn...@ec...
ISIS                        http://www.ecs.soton.ac.uk/~jnc/

[libdv-dev] bootstrap is hard !

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

Hi,

with current CVS version I'll get the following bootstrap errors:
-- snip -----------------------------------
lucke@jarada:/home/src/IEEE-1394/libdv-orig > bootstrap
+ aclocal -I config
aclocal: config/glib.m4: 8: duplicated macro `AM_PATH_GLIB'
aclocal: config/gtk.m4: 7: duplicated macro `AM_PATH_GTK'
+ libtoolize --force --copy
You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
Putting files in AC_CONFIG_AUX_DIR, `config'.
+ autoheader
+ automake --foreign --copy --add-missing
automake: configure.in: installing `config/install-sh'
    error while copying

automake: configure.in: installing `config/mkinstalldirs'
    error while copying

automake: configure.in: installing `config/missing'
    error while copying

+ autoconf
autoconf: Undefined macros:
configure.in:104:               AC_DEFINE_UNQUOTED(DEBUG,$with_debug)
configure.in:110:  AC_DEFINE(DEBUG)
configure.in:11:AC_DISABLE_SHARED
configure.in:123:       AC_DEFINE(HAVE_GLIB)
configure.in:127:       AC_MSG_ERROR([No glib. Bad.  Get it at:  http://www.gtk.org/. ])
configure.in:132:       AC_DEFINE(HAVE_GTK)
configure.in:140:               AC_DEFINE(HAVE_SDL)
configure.in:173:AC_C_BIGENDIAN_CROSS
configure.in:30:AC_DEFINE(_GNU_SOURCE)
configure.in:66:                        AC_DEFINE(ARCH_X86)
configure.in:79:                AC_DEFINE(YUV_420_USE_YV12)
configure.in:99:                AC_DEFINE(DEBUG)
lucke@jarada:/home/src/IEEE-1394/libdv-orig > 
-- snip -----------------------------------
To resolve these issues, I had to remove the recently added files:
config/glib.m4
config/gtk.m4

So for my enviroment sdl.m4 is the only one, which should be placed in config.
Does this happen to my old distro SuSe 6.3 only ?


-- 

mfg

  Stefan Lucke (Ste...@sn...)

RE: [libdv-dev] ntsc / pal issue .

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

I have heard too that the Sony PC100 can play both NTSC and PAL tapes, so 
it is not unlikely that it can record both formats too.

dvgrab will create a new file when in autosplit mode. You need only to make 
sure that the new file is properly created as an NTSC or PAL file. There is 
a little piece of code querying for this before opening the first file, 
should be a trivial change.


Arne

-----Original Message-----
From:	Lukas Knutsson
Sent:	Thursday, April 05, 2001 11:54 AM
To:	lib...@so...
Subject:	[libdv-dev] ntsc / pal issue .

Not directly related to libdv, but an answer to this would help my
understanding of DV.

A friend of mine with a NTSC Sony PC 100 managed to firewire over his
footage to my PAL PC100, and I could watch it on my PAL camera's
viewfinder. I doubt that a conversion was made, so is it possible that
my camera can play up both DV formats ?

Now I am having trouble capturing the footage to my hard drive using a
commercial product, a well established app being 'premiered' at my
computer.

Could dvgrab capture it ? (ie capture the NTSC segments in the middle of
my PAL segments)

Has anybody written or is working on a NTSC <-> PAL converter utility ?

<lukas/>

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

Re: [libdv-dev] ntsc / pal issue .

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

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

> Not directly related to libdv, but an answer to this would help my
> understanding of DV.

> A friend of mine with a NTSC Sony PC 100 managed to firewire over
> his footage to my PAL PC100, and I could watch it on my PAL camera's
> viewfinder. I doubt that a conversion was made, so is it possible
> that my camera can play up both DV formats ?

I don't know for sure.  I'd say it's pretty reasonable that the camera
could play both formats.  I too doubt that any conversion is made.
You could verify it by trying the analog out of your camera with a TV.

> Now I am having trouble capturing the footage to my hard drive using
> a commercial product, a well established app being 'premiered' at my
> computer.

That's strange.

> Could dvgrab capture it ? (ie capture the NTSC segments in the
> middle of my PAL segments)

Yes.  It should play with libdv too.  There was code added a while ago
to detect format changes.

> Has anybody written or is working on a NTSC <-> PAL converter
> utility ?

I don't know if there are any free ones.  It would be a nice project.

I know Canopus have a commercial one.

> <lukas/>

-- Buck

[libdv-dev] ntsc / pal issue .

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

Not directly related to libdv, but an answer to this would help my
understanding of DV.

A friend of mine with a NTSC Sony PC 100 managed to firewire over his
footage to my PAL PC100, and I could watch it on my PAL camera's
viewfinder. I doubt that a conversion was made, so is it possible that
my camera can play up both DV formats ?

Now I am having trouble capturing the footage to my hard drive using a
commercial product, a well established app being 'premiered' at my
computer.

Could dvgrab capture it ? (ie capture the NTSC segments in the middle of
my PAL segments)

Has anybody written or is working on a NTSC <-> PAL converter utility ? 

<lukas/>

[libdv-dev] Is it patch time now ?

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

Hi,

I made the following changes (from Changelog):

* New options (available for Xv only):
	--aspect ([w|wide|n|normal])
	--size (10 .. 100)

* Reenabled scaling with Xv. Aspect ratio is keept constant when
  --aspect option is specified. This depends on used window
  manager too. KDE :-(( , fvwm, enlightment :-)

* Changed all render functions to have the same paramerlist

* Bug fixes:
  According to SDL linux FAQ: Applications which support
  SDL should have an sdl.m4 file in their config.

  Assembler error messages with encode_x86.S
  my one does not like div operations with defines.
  replaced DV_WIDTH/2 by DV_WIDTH_2	

patch is available at:
	http://home.snafu.de/lucke/patch.dv.3003.bz2

-- 

mfg

  Stefan Lucke (Ste...@sn...)

[libdv-dev] [ libdv-Patches-412309 ] encoder improvements

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

Patches item #412309, was updated on 2001-03-29 14:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=412309&group_id=4393

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Peter Schlaile (schlaile)
Assigned to: Nobody/Anonymous (nobody)
Summary: encoder improvements

Initial Comment:
* VLC encoder improvements: Now it's more correct for 3
passes (but
  also slower...), faster for 2 passes. Implemented
turbo mode 
  (static qno tables). Hopefully makes the thing
finally realtime on 
  an Athlon 800...
* Separated out the input and output queue. Build
general input and
  output filter plugin system. Included /dev/video
support.
* several assembler optimized routines in the vlc
encoder added, 
  reorder_88 code is now merged with the DCT postscaler
to fill the 
  integer pipelines _and_ the MMX pipelines
* renamed encode to encodedv
* removed blur function since it doesn't make sense
* corrected (?) faster C version of convert_to_yuv


Since this patch is large you can find it at
http://www.uni-karlsruhe.de/~udbz/linux/libdv.patch

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=412309&group_id=4393

[libdv-dev] [ libdv-Patches-409980 ] Missing include in headers.c

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

Patches item #409980, was updated on 2001-03-20 02:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=409980&group_id=4393

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Daniel Kobras (nold)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing include in headers.c

Initial Comment:
headers.c in current CVS misses an include of time.h.
Compilation fails for me otherwise. Obvious fix
attached.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=409980&group_id=4393

Re: [libdv-dev] Getting RGB-Data from DV

[Oliver S. <oli...@gm...>]

On Sunday 18 March 2001 19:10, Charles 'Buck' Krasic wrote:
> If you just want the RGB data, you don't need andy of the dv_display_X
> calls.  Instead you should call dv_decode_full_frame with something like:
>
> [...]

Works fine now. Thank you very much. But as always this raises another 
question. Actually I would prefer RGBA or ARGB data because I need the alpha
byte later on. Of course reading alpha values with a camera does not make any 
sense, but I wonder if it is possible to get a data buffer with an alpha 
channel (probably set to some constant value) directly from libdv as it 
requires manual copying and insertion of the alpha byte otherwise which slows 
down display drastically.

Thanks, Oliver

-- 
_____________________________________________________________________
 Oliver Strutynski                                oli...@in...

Re: [libdv-dev] Getting RGB-Data from DV

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

Oliver Strutynski <oli...@gm...> writes:

> Based on the playdv-code I am currently trying to get RGB data from a DV 
> movie for display as a background image in an OpenGL application. At the 
> moment I am still creating and initializing the display as it is done in 
> playdv.c and I am trying to display the data returned from the call to 
> dv_decode_full_frame in OpenGL.

If you just want the RGB data, you don't need andy of the dv_display_X
calls.  Instead you should call dv_decode_full_frame with something like:

        gint16  pitches[3];  
        guchar *pixels [3];

        pixels[0]  = gmalloc(dv_player->decoder->width * dv_player->decoder->height * 3);
        pitches[0] = { dv_player->decoder->width };

         ...

	dv_decode_full_frame(dv_player->decoder, dv_player->mmap_region.data_start, 
			     e_dv_color_rgb,
                             pixels,
                             &pitches[0]);

         ...

        your_gl_render_fn(...pixels[0]...)

-- Buck

[libdv-dev] Getting RGB-Data from DV

[Oliver S. <oli...@gm...>]

Based on the playdv-code I am currently trying to get RGB data from a DV 
movie for display as a background image in an OpenGL application. At the 
moment I am still creating and initializing the display as it is done in 
playdv.c and I am trying to display the data returned from the call to 
dv_decode_full_frame in OpenGL.

The problem is that OpenGL just displays lots of (random?) pixels. So I guess 
libdv does not return RGB data. However I could not figure out how to get RGB 
data from libdv, or if that's not possible how to convert the data returned 
by libdv to RGB.

I would really appreciate any help. Thanks a lot, Oliver

-- 
_____________________________________________________________________
 Oliver Strutynski                                oli...@in...

[libdv-dev] [ libdv-Bugs-409276 ] linuxppc compile fails on libdv.lo

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

Bugs item #409276, was updated on 2001-03-16 15:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104393&aid=409276&group_id=4393

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: linuxppc compile fails on libdv.lo

Initial Comment:
Trying to build on a PowerBook G3, Debian dist with a
recent LinuxPPC kernel.  I've tried gcc 2.95.2 and egcs
1.1.2. Attached below are more detailed results.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104393&aid=409276&group_id=4393

[libdv-dev] playdv quicker without assembler routines

[Stein-Erik <se...@in...>]

Hello!

I have been playing with playdv in the    libdv-0.6
release for a couple of days now - I have just gotten my
'graphics machine' put together.

I have added a timing routine like this:
    struct timeval seenTime;
    long  seenLast = 0;

    void showTime( char *text ) {

      long usec, diff;

      gettimeofday( &seenTime, NULL );

      usec = seenTime.tv_usec;
      diff = usec - seenLast;
      seenLast = usec;

      printf( "%18s : %6ld, %6ld\n", text, usec, diff );
   }
and adding    ShowTime( "sensible text" )    at proper
places, to check the speed of the different parts, and to
see the effect of commenting out different parts.

The routine   dv_decode_full_frame   in dv.c has been one of
those I have looked at. Each of the ds loops (12 all in all
on my system) takes around 1700 microseconds, and on my 4
seconds test film (100 frames) I get 26.81 - 27.09 fps. This
is with the audio (the dv_oss_play call in playdv.c)
commented out.

When I (as part of many tests) removed the assembler code
for
    dv_parse_video_segment
and
    dv_parse_ac_coeffs_pass0
(by commenting out    #if  ! ARCH_X86    and   #endif, and
renaming the corresponding 2 names in   vlc_x86.S   to
xdv_parse_...), I got an   *increase*   in speed. Now it
averaged 1500 microseconds for each ds loop, and 28.05 -
28.15 fps! So the C code is actually quite a bit faster than
the assembler code...

I also tried to remove the assembler code for the other 2
routines in    vlc_x86.S   , but that increased the time
from around 1500 microseconds per loop, to around 1900...

Has the C code been optimized without the assembler code
following on, or is the compiler better at finding good
instructions here?

I am running on an AMD 1.2 GHz processor with 266 MHz memory
bus, 256 MB 133 MHz RAM, SuSE 7.1, but with a clean 2.4.2
kernel with the newest firewire patch (as of a week
ago...:.), XFree86 4.0.2, 45 MB 7200 IBM IDE disk, which
with   hdparm -tT   gives 35.5 MB/s after enabling udma5,
CardExpert GeForce 2 Pro/400, and the NVidia optimized
driver with 2D and 3D optimizations, 1024x768 resolution, 16
bits. The  gears  program stabilizes on 1710-1711 FPS (as a
measure of the OpenGL 3D speed). The Xvideo extension is
used by playdv, when I commented that out the performance
dropped below 20 fps.

I am also looking into extending playdv a bit:
    - Making it react to keyboard keys to stop, start, play
slowly, play backwards etc.
I don't want to add mouse operations,  its only the keyboard
handling I'd like, to be able to scroll back an forwards,
move a frame at a time etc.

The changes will mostly affect the main loop in playdv.c -
make it have a frame index as the main loop counter, and
knowing the first and last frame available, instead of the
offset it has today, to easily be able to go to the next
frame, the previous frame etc. Also synchronization will be
needed - at least without sound I am able to get it to go
quicker than the 25 fps PAL is supposed to be.

Are anybody else doing anything with playdv, or is this OK?
I am planning on sending it back, to let the one responsible
include it as the playdv program, if it works as I want it
to.

Regards,
   Stein-Erik

[libdv-dev] [ libdv-Patches-407986 ] Compiling error!!

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

Patches #407986, was updated on 2001-03-12 10:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=407986&group_id=4393

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: victor Dong
Assigned to: Nobody/Anonymous
Summary: Compiling error!!

Initial Comment:


Hi: 
I just downloaded the libdv-0.6 and when I compile it, 
I got these error messages:
encode_x86.S:265: unterminated character constant
encode_x86.S:266: unterminated character constant     

I opened the encode_x86.s and found line 265 and 266 
are just comments, so I removed then and try to 
compile again, then I got more error messages: 
Can I anyone tell me what is wrong? ./configure is 
successful. I am using Debian-2.2.16. Thanks!

Victor

display.c: In function `dv_display_set_norm':
display.c:259: structure has no member named `sheight'
display.c: In function `dv_display_check_format':
display.c:268: structure has no member named
`pic_format'
display.c:269: structure has no member named `flags'
display.c:269: `XV_FORMAT_MASK' undeclared (first use
in this function)
display.c:269: (Each undeclared identifier is reported
only once
display.c:269: for each function it appears in.)
display.c:273: `DV_FORMAT_UNKNOWN' undeclared (first
use in this function)
display.c:276: `DV_FORMAT_NORMAL' undeclared (first
use in this function)
display.c:277: structure has no member named `flags'
display.c:277: `XV_FORMAT_WIDE' undeclared (first use
in this function)
display.c:281: structure has no member named `lyoff'
display.c:282: structure has no member named `dheight'
display.c:282: structure has no member named `lheight'
display.c:283: structure has no member named `dwidth'
display.c:283: structure has no member named `lwidth'
display.c:284: structure has no member named `lxoff'
display.c:289: structure has no member named `lxoff'
display.c:289: structure has no member named `lyoff'
display.c:290: structure has no member named `dwidth'
display.c:290: structure has no member named `lwidth'
display.c:291: structure has no member named `dheight'
display.c:291: structure has no member named `lheight'


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=407986&group_id=4393

[libdv-dev] [ libdv-Patches-407395 ] vast encoder improvements (3 VLC passes)

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

Patches #407395, was updated on 2001-03-09 12:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=407395&group_id=4393

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Peter Schlaile
Assigned to: Nobody/Anonymous
Summary: vast encoder improvements (3 VLC passes)

Initial Comment:
* VLC encoder improvements: Now we do 3 passes and we
do it even
   better than my Sony Camcorder ;-)
* need_dct_248 fixes, weighting fixes, seperated out
the header
   writer and a lot more things I've forgotten
* NTSC encoding works now really
* rgbtoyuv now adapts correctly to the encoding system
(PAL or NTSC)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=407395&group_id=4393

[libdv-dev] [Patch #103887] encoder speedups and quantization fixes

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

Patch #103887 has been updated. 

Project: libdv
Category: None
Status: Open
Submitted by: schlaile
Assigned to : nobody
Summary: encoder speedups and quantization fixes

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=103887&group_id=4393

[libdv-dev] [Patch #103845] forgotten quant.c patch

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

Patch #103845 has been updated. 

Project: libdv
Category: None
Status: Open
Submitted by: schlaile
Assigned to : nobody
Summary: forgotten quant.c patch

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=103845&group_id=4393