libdv-dev

[libdv-dev] Kino CVS repository available

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

I have uploaded the latest Kino source code to Sourceforge. The url is 
http://sourceforge.net/projects/kino/ .This code is almost the same as in 
the v. 0.33 release, with Dan's last patch merged in.

If you would like to contribute to Kino, please use this cvs version as the 
base and send me a diff, or better send me your Sourceforge ID so that I 
can give you write access to the cvs .

Arne 

[libdv-dev] bootstrap, Makefile.vanilla

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

Hi,

just tried the latest version (checked out friday).
- bootstrap: does not work (error log attached)

- Makefile.vanilla (old style Makefile ?): does not work either
  There should be the following changes:
	see attached file
-- 

mfg

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

Re: [libdv-dev] Where to go ? (SORRY)

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

On Fre, 29 Dez 2000, I wrote something:

Hi,

this message accidently left my outbox, sorry. I don't know why.
It's just an unfinished/draft collection of thoughts/wishes,
one of them (audio extraction) has already started.

-- 

mfg

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

RE: [libdv-dev] Where to go ?

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

My wish list:

speed: a way do do 25 or 30 fps even on slower hardware, maybe with a half 
or quarter size image and other tradeoffs. Currently, scaling down the 
image slows it down even more (it's an additional phase).

quality: somebody said the mmx routines are less precise than real floating 
point routines. For image processing (conversion to mpeg) I need the best 
possible input, regardless of cpu time. These would be overnight jobs 
anyway.

de-interlacing: the interlacing effects are annoying.

I do not believe we need more features in the sample program. There are 
plenty of Xv-, SDL- and other sample programs around.

Audio might need some work and testing. I have some audio code in the 
dvgrab program (for writing type 2 avi files, which need a separate audio 
track) and I am not sure everything is correct. It sounds reasonable with 
my equipment though. I did not look into libdv's recent audio additions 
yet.

Arne


-----Original Message-----
From:	Stefan Lucke
Sent:	Friday, December 29, 2000 9:31 PM
To:	lib...@li...
Subject:	[libdv-dev] Where to go ?

Hi,

what about the future of libdv ?

During the last months Buck is the only one of the original developers
who takes care of libdv.

- output format selection
  Our sample applicatiopn should take care of
  - direct output (X11) only if desired.
  - possible intermix of PAL/NTSC
  -> select output buffers in a way that at least two frames could
     be placed in.
- audio extraction
- sample application
- tests cases
- encoding (dct88 vs. dct 248)
  When to use dct248 insteadof dct 88
  From my experience 248 is used when there are significant differences
  in Y values within a macro block (segement)
  Upper left <-> lower right.
  So for encoding we need a function like
	dv_enc_use_dct248 (dv_macroblock_t *mb)

- new functions:
	typedef enum { normal, wide} dv_format_t;

	int		dv_enc_use_dct248 (dv_macroblock_t *mb)
	int		dv_dec_is_wide_screen (dv_frame_t *fr)

	dv_format_t	dv_notify_format_change (void);
	dv_system_t	dv_notify_system_change (void);
--

mfg

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

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

Re: [libdv-dev] Where to go ?

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

On Fri, 29 Dec 2000, Stefan Lucke wrote:

> During the last months Buck is the only one of the original developers
> who takes care of libdv.

I'll be doing some work on libdv at some point in the future, but I've
been focusing on GStreamer for the past couple months.  I'll be added a
libdv plugin to it, which is why I'll be working on libdv ;-)  You can
read more at gstreamer.net.

TTYL,
    Omega

      Erik Walthinsen <om...@te...> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_

[libdv-dev] Where to go ?

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

Hi,

what about the future of libdv ?

During the last months Buck is the only one of the original developers
who takes care of libdv.

- output format selection
  Our sample applicatiopn should take care of
  - direct output (X11) only if desired.
  - possible intermix of PAL/NTSC
  -> select output buffers in a way that at least two frames could
     be placed in.
- audio extraction
- sample application
- tests cases
- encoding (dct88 vs. dct 248)
  When to use dct248 insteadof dct 88
  From my experience 248 is used when there are significant differences
  in Y values within a macro block (segement)
  Upper left <-> lower right.
  So for encoding we need a function like
	dv_enc_use_dct248 (dv_macroblock_t *mb)

- new functions:
	typedef enum { normal, wide} dv_format_t;

	int		dv_enc_use_dct248 (dv_macroblock_t *mb)
	int		dv_dec_is_wide_screen (dv_frame_t *fr)

	dv_format_t	dv_notify_format_change (void);
	dv_system_t	dv_notify_system_change (void);
-- 

mfg

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

[libdv-dev] Kino 0.33 now exports movies to camcorder

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

Hi all,

after I got Peter's new video driver and sample code, I could finally add 
the "Export to camcorder" function that everybody wants. It looks great so 
far. Please test this with NTSC equipment too (I don't have access to this) 
and mail a note if it works or not.

I think the ieee1394 project has now reached a major milestone. Many thanks 
to everybody involved.

The kino tar file contains my working snapshot of the ieee1394 driver plus 
Peter's modifications. I am not sure whether these are already in CVS. It 
contains also a modified version of libdv, which has additional conversion 
functions for use with faster gdk routines.

I got several patches and bugfixes for both kino and dvgrab in the last 
weeks, which I could not yet integrate (lack of time). The version 0.4 will 
have it all. I hope.

The tar file can be downloaded from 
http://www.schirmacher.de/arne/kino/kino_0.33.tar.gz .

Arne

Re: [libdv-dev] [Bug #128255] dv.c and parse.c

[Cheryl F. <ch...@vi...>]

Hi, Buck!  Thanks for getting back so quickly.

Ah. There was no 'configure' script as indicated in
step one of "INSTALL", so I'd run automake and autoconf
by hand, to no avail. This action perhaps hosed the 
files such that 'bootstrap' then didn't work.  So I 
went to Makefile.vanilla and edited it by hand.   

Now I've restored the source exactly as it came out of 
the CVS repository.  *Now* ./bootstrap has produced a
good ./configure.  (Appreciate your use of auto tools btw.)

However, having re-installed the libdv.a (and ranlibbed
it in place) I still see the same undefined references
when linking to kino. 

We're testing this code for a DIP application on DV data,
so I'm not too fussed about the audio tracks at all--will 
stick to the snapshot provided with kino. (Might there 
ultimately be an option, I wonder, to send the audio track 
to /dev/null and run without a sound card, return a nice
"tout va bien" from the libdv functions nevertheless?)

I'd gone and ordered some of the IEC specs, and blanched 
at the prospect of writing a decoder in the time frames 
we're working under, so, really, thanks heaps for libdv.  

Cheryl

On 9 Jan 2001, Charles 'Buck' Krasic wrote:

> 
> Whoops... This is because of some new code I've put in for audio
> decoding.  It works for 44Khz/16bit.  I have 12 bit working with very
> bad distortion (I can't figure out why).
> 
> Anyway, I havn't had a chance to update Makefile.vanilla to reflect
> the new audio code (hence the build errors).
> 
> The instructions for building via autotools are in the README.
> 
> Basically, you need to do "./bootstrap" to get a configure file.
> 
> -- Buck
> 
> 
> no...@so... writes:
> 
> > Bug #128255, was updated on 2001-Jan-09 22:49
> > Here is a current snapshot of the bug.
> > 
> > Project: Quasar DV Codec
> > Category: None
> > Status: Open
> > Resolution: None
> > Bug Group: None
> > Priority: 5
> > Submitted by: nobody
> > Assigned to : nobody
> > Summary: dv.c and parse.c 
> > 
> > Details: please reply to ch...@vi...
> > 
> > it seems that dv.c is trying to reference an
> > unknown function dv_decode_full
> > 
> > This is under SuSE 7.0, vanilla install, with gcc-2.95.2-100, trying to
> > link libdv.a to build
> > kino: 
> > 
> > seems to be (in current snapshot) there are a 
> > few dangling references.  This was using
> > 
> > make -f Makefile.vanilla to generate libdv
> > where kgcc is replaced by gcc right at the top.
> > 
> > 
> > /usr/local/lib/libdv.a(dv.o): In function `dv_decode_full_audio':
> > /home/cheryl/Firewire/libdv/dv.c:340: undefined reference to
> > `dv_update_num_samples'
> > /home/cheryl/Firewire/libdv/dv.c:345: undefined reference to
> > `dv_decode_audio_block'
> > /usr/local/lib/libdv.a(parse.o): In function `dv_parse_header':
> > /home/cheryl/Firewire/libdv/parse.c:578: undefined reference to
> > `dv_parse_audio_header'         
> > 
> > Also, ./configure is not there, and running autoconf, automake doesn't seem
> > to generate any .configure  --
> > 
> > It turns out that there is an older libdv snapshot 
> > distributed with kino (possibly tweaked) that does
> > link OK -- so...well, we'll see how it works.
> > 
> > realize this is alpha code, and lots of it, so good work.  
> > 
> > Thanks
> > 
> > Cheryl
> > please reply to ch...@vi...
> > 
> > For detailed info, follow this link:
> > http://sourceforge.net/bugs/?func=detailbug&bug_id=128255&group_id=4393
> > 
> > _______________________________________________
> > libdv-dev mailing list
> > lib...@li...
> > http://lists.sourceforge.net/mailman/listinfo/libdv-dev
> 

[libdv-dev] encode problems

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

As mentioned earlier I couldn't watch a movie built with encode (well
actually any movie). Well I trundled over to a Mac with my dv movie and
couldn't watch it with Quicktime, which should be able to play raw dv
files, and couldn't open it in Final Cut Pro either. It certainly seems
that it isn't a correct dv file.

Any ideas ? 

For those with bandwidth the file is at
http://zelda.spray.se/~lukas/intf.dv and is 7Mb (exactly 2 secs, 50
frames).

/Lukas

Re: [libdv-dev] weird dv format

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

> Please check out the file http://www.schirmacher.de/tmp/test001.avi . It 
> displays correctly under Windows, but not using the libdv codec. It has 
> been created with a PAL Panasonic NV-DX100, however the Windows mediaplayer 
> says it is a NTSC file. The DIF Sequence Flag bit in the header is in fact 
> zero. If I force this to one, then the display under Linux is ok.
> 
> Do you have any idea why the dv data seems to be inconsistent? Is there 
> another way of discriminating between PAL and NTSC besides using the DSF 
> bit? I have already seen this problem earlier, maybe we need a workaround 
> allowing for broken camcorders.
SMPTE314M page 12. There is another 50/60 bit in VAUX packed 0x60
pack_data [0] == 0x60, pack_data [3] & 0x20 -> 50 if bit set. Could you check this ?

Stefan
Lucke

Re: [libdv-dev] weird dv format

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

Arne Schirmacher wrote:
> 
> Please check out the file http://www.schirmacher.de/tmp/test001.avi . It
> displays correctly under Windows, but not using the libdv codec. It has
> been created with a PAL Panasonic NV-DX100, however the Windows mediaplayer
> says it is a NTSC file. The DIF Sequence Flag bit in the header is in fact
> zero. If I force this to one, then the display under Linux is ok.
> 
> Do you have any idea why the dv data seems to be inconsistent? Is there
> another way of discriminating between PAL and NTSC besides using the DSF
> bit? I have already seen this problem earlier, maybe we need a workaround
> allowing for broken camcorders.

When I attempt to play the pond.dv file I see this,

[lukas@sto-lknutsson libdv]$ ./playdv ../pond.dv 
Audio is 44.1 kHz, 16 bits linear quantization, 2 channels
Xlib:  extension "XVideo" missing on display ":0.0".
Xlib:  extension "XVideo" missing on display ":0.0".
 Using gtk for display
Displayed 915 frames in 29.86 seconds (30.65 fps)

pretty good except I didn't see anything in the window, but I did hear
the soundtrack.

I created a video using encode but I couldn't watch it at all. 

[lukas@sto-lknutsson libdv]$ ./playdv ~/src/intf/data/intf.dv 
Xlib:  extension "XVideo" missing on display ":0.0".
Xlib:  extension "XVideo" missing on display ":0.0".
 Using gtk for display
soundcard doesn't support stereo
Displayed 50 frames in 00.00 seconds (102669.40 fps)

Funny encode doesn't even create a soundtrack. I am using the latest
stuff from CVS. I then did a ./configure --disable-xv but nothing
changed. In fact it still seemed to check for xv support,

[lukas@sto-lknutsson libdv]$ ./playdv ../pond.dv 
Audio is 44.1 kHz, 16 bits linear quantization, 2 channels
Xlib:  extension "XVideo" missing on display ":0.0".
 Using gtk for display
Displayed 915 frames in 29.85 seconds (30.66 fps)

/Lukas

[libdv-dev] weird dv format

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

Please check out the file http://www.schirmacher.de/tmp/test001.avi . It 
displays correctly under Windows, but not using the libdv codec. It has 
been created with a PAL Panasonic NV-DX100, however the Windows mediaplayer 
says it is a NTSC file. The DIF Sequence Flag bit in the header is in fact 
zero. If I force this to one, then the display under Linux is ok.

Do you have any idea why the dv data seems to be inconsistent? Is there 
another way of discriminating between PAL and NTSC besides using the DSF 
bit? I have already seen this problem earlier, maybe we need a workaround 
allowing for broken camcorders.

Arne

Re: [libdv-dev] [Bug #128255] dv.c and parse.c

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

Whoops... This is because of some new code I've put in for audio
decoding.  It works for 44Khz/16bit.  I have 12 bit working with very
bad distortion (I can't figure out why).

Anyway, I havn't had a chance to update Makefile.vanilla to reflect
the new audio code (hence the build errors).

The instructions for building via autotools are in the README.

Basically, you need to do "./bootstrap" to get a configure file.

-- Buck


no...@so... writes:

> Bug #128255, was updated on 2001-Jan-09 22:49
> Here is a current snapshot of the bug.
> 
> Project: Quasar DV Codec
> Category: None
> Status: Open
> Resolution: None
> Bug Group: None
> Priority: 5
> Submitted by: nobody
> Assigned to : nobody
> Summary: dv.c and parse.c 
> 
> Details: please reply to ch...@vi...
> 
> it seems that dv.c is trying to reference an
> unknown function dv_decode_full
> 
> This is under SuSE 7.0, vanilla install, with gcc-2.95.2-100, trying to
> link libdv.a to build
> kino: 
> 
> seems to be (in current snapshot) there are a 
> few dangling references.  This was using
> 
> make -f Makefile.vanilla to generate libdv
> where kgcc is replaced by gcc right at the top.
> 
> 
> /usr/local/lib/libdv.a(dv.o): In function `dv_decode_full_audio':
> /home/cheryl/Firewire/libdv/dv.c:340: undefined reference to
> `dv_update_num_samples'
> /home/cheryl/Firewire/libdv/dv.c:345: undefined reference to
> `dv_decode_audio_block'
> /usr/local/lib/libdv.a(parse.o): In function `dv_parse_header':
> /home/cheryl/Firewire/libdv/parse.c:578: undefined reference to
> `dv_parse_audio_header'         
> 
> Also, ./configure is not there, and running autoconf, automake doesn't seem
> to generate any .configure  --
> 
> It turns out that there is an older libdv snapshot 
> distributed with kino (possibly tweaked) that does
> link OK -- so...well, we'll see how it works.
> 
> realize this is alpha code, and lots of it, so good work.  
> 
> Thanks
> 
> Cheryl
> please reply to ch...@vi...
> 
> For detailed info, follow this link:
> http://sourceforge.net/bugs/?func=detailbug&bug_id=128255&group_id=4393
> 
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> http://lists.sourceforge.net/mailman/listinfo/libdv-dev

[libdv-dev] [Bug #128255] dv.c and parse.c

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

Bug #128255, was updated on 2001-Jan-09 22:49
Here is a current snapshot of the bug.

Project: Quasar DV Codec
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: dv.c and parse.c 

Details: please reply to ch...@vi...

it seems that dv.c is trying to reference an
unknown function dv_decode_full

This is under SuSE 7.0, vanilla install, with gcc-2.95.2-100, trying to
link libdv.a to build
kino: 

seems to be (in current snapshot) there are a 
few dangling references.  This was using

make -f Makefile.vanilla to generate libdv
where kgcc is replaced by gcc right at the top.


/usr/local/lib/libdv.a(dv.o): In function `dv_decode_full_audio':
/home/cheryl/Firewire/libdv/dv.c:340: undefined reference to
`dv_update_num_samples'
/home/cheryl/Firewire/libdv/dv.c:345: undefined reference to
`dv_decode_audio_block'
/usr/local/lib/libdv.a(parse.o): In function `dv_parse_header':
/home/cheryl/Firewire/libdv/parse.c:578: undefined reference to
`dv_parse_audio_header'         

Also, ./configure is not there, and running autoconf, automake doesn't seem
to generate any .configure  --

It turns out that there is an older libdv snapshot 
distributed with kino (possibly tweaked) that does
link OK -- so...well, we'll see how it works.

realize this is alpha code, and lots of it, so good work.  

Thanks

Cheryl
please reply to ch...@vi...

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

Re: [libdv-dev] libdv change request

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

Thanks, I'll take a look.

Since you seem to be interested in speeding up display, you might want
to look into the source code for VirtualDub or FlaskMPEG.  They are GPL.

They both have x86 assembly and MMX tuned versions of YUV to RGB
(16,24,and 32bpp).  They look like the same code, but I'm not sure who
wrote it originally.  

They're both windows programs, but it shouldn't be so hard to adapt to
code to Linux.  

My experience in the past has been that RGB 16 is significantly faster
than 24 or 32bpp.  

I bet that with carefull tuning, you could get performance close to Xv
with those codes.  The difference is that Xv gives access to HW
scaling for free.

Also, it might be worth looking into OpenGL textures, as there seems
to be more work on HW drivers for Linux there (with NVidia and DRI).
OpenGL might be another avenue to some HW scaling (probably not as nice
as Xv though).

-- Buck

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

> I did some performance measurements using several kinds of X display
> methods.

> Using the hardware supported Xv mode is of course the fastest (but
> could be made even faster by using XvShmPutImage, as a developer
> pointed out on the Xpert mailing list. I will implement that later).

> When the depth of the display is 24 bit and 4 bytes per pixel, then
> using gdk_put_image is faster (17.5 fps on my system) than using
> gdk_put_rgb (13 fps on my system). Unfortunately, it needs a byte
> order of blue, green, red and an unused value so I have to rearrange
> the bytes delivered from libdv, which uses up most of the
> performance gain.

> I have added a few routines to rgb.c and dv.c which implement this
> new byte ordering. It is simply duplicated code with the only
> difference being the *p++ = r; *p++ = g; etc. reordered to match the
> bgr0 order requirement. I don't really like duplicated code but I
> did not wanted to put if statements in those tight loops, but maybe
> you have an idea how to solve this both elegant and efficient.

> The modified libdv code is under 
> http://www.schirmacher.de/tmp/libdv-2001-01-07.patched.tar.gz .

> Arne

[libdv-dev] libdv change request

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

I did some performance measurements using several kinds of X display 
methods.

Using the hardware supported Xv mode is of course the fastest (but could be 
made even faster by using XvShmPutImage, as a developer pointed out on the 
Xpert mailing list. I will implement that later).

When the depth of the display is 24 bit and 4 bytes per pixel, then using 
gdk_put_image is faster (17.5 fps on my system) than using gdk_put_rgb (13 
fps on my system). Unfortunately, it needs a byte order of blue, green, red 
and an unused value so I have to rearrange the bytes delivered from libdv, 
which uses up most of the performance gain.

I have added a few routines to rgb.c and dv.c which implement this new byte 
ordering. It is simply duplicated code with the only difference being the 
*p++ = r; *p++ = g; etc. reordered to match the bgr0 order requirement. I 
don't really like duplicated code but I did not wanted to put if statements 
in those tight loops, but maybe you have an idea how to solve this both 
elegant and efficient.

The modified libdv code is under 
http://www.schirmacher.de/tmp/libdv-2001-01-07.patched.tar.gz .

Arne

Re: [libdv-dev] Problems with libdv

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

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

> Please see this file to reproduce the problem:

> http://www.schirmacher.de/tmp/bug4.dv

> The bug shows only when using the gtk display, not when using Xv. So I 
> guess it must be somewhere in the RGB conversion.

Yes, it was reproduced on my side.  I seemed to have fixed it, by
expanding the range of the YUV clamp table.  

> This file shows more color conversion problems: Check the orange balloon. 
> This is also visible only in the gtk display version of playdv.

> http://www.schirmacher.de/tmp/bug1.dv

Yes, I see it, but I don't have a fix yet.  

> I noticed a strange effect when running playdv and using the Xv display 
> method: It incorrectly calculates the fps value printed to stdout. It 
> prints only "nan". I have a similar effect in Kino, where I calculated a 
> fps value too. Maybe this has something to do with fpu registers used by 
> mmx code?

Got it, I think.  There was a emms() call missing in the YV12 conversion code.

> The header files now correctly compile under C++, however the result won't 
> link because the 'extern "C" { ' directive is missing. (Sorry, I forgot to 
> mention this in the last email).

Ok, I've added these to the exported header files.

All of these changes are in CVS now.

-- Buck

[libdv-dev] Patch to configure.in allowing --disable-sdl

[Scott F. J. <sc...@fl...>]

This is a quick patch to configure.in to allow the use of --disable-sdl
when running configure. This results in a gtk-only version of playdv and
makes it easier for testing various configurations.
It also prevents configure from checking to see if SDL is installed,
allowing
libdv to build on machines without SDL, or with SDL < 1.1.6.
After applying, run autoconf to build a new configure script from
configure.in.

--Scott

diff -r1.1 configure.in
24a25,31
> use_sdl=:
> AC_ARG_ENABLE(sdl,
> [  --disable-sdl           disable use of SDL for display],
> [     if test "$enableval" = "no"; then
>               use_sdl=false
>       fi
> ])
54,61c61,70
< AM_PATH_SDL(1.1.6,
< [
<       AC_DEFINE(HAVE_SDL)
<       LIBS="$LIBS $SDL_LIBS"
<       CFLAGS="$CFLAGS $SDL_CFLAGS"
< ])
< dnl Replace `main' with a function in -lXv:
< AC_CHECK_LIB(Xv,XvQueryAdaptors,)
---
> if $use_sdl; then
>       AM_PATH_SDL(1.1.6,
>       [
>               AC_DEFINE(HAVE_SDL)
>               LIBS="$LIBS $SDL_LIBS"
>               CFLAGS="$CFLAGS $SDL_CFLAGS"
>       ])
>       dnl Replace `main' with a function in -lXv:
>       AC_CHECK_LIB(Xv,XvQueryAdaptors,)
> fi

RE: [libdv-dev] Problems with libdv

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

Please see this file to reproduce the problem:

http://www.schirmacher.de/tmp/bug4.dv

The bug shows only when using the gtk display, not when using Xv. So I 
guess it must be somewhere in the RGB conversion.

This file shows more color conversion problems: Check the orange balloon. 
This is also visible only in the gtk display version of playdv.

http://www.schirmacher.de/tmp/bug1.dv

I noticed a strange effect when running playdv and using the Xv display 
method: It incorrectly calculates the fps value printed to stdout. It 
prints only "nan". I have a similar effect in Kino, where I calculated a 
fps value too. Maybe this has something to do with fpu registers used by 
mmx code?

The header files now correctly compile under C++, however the result won't 
link because the 'extern "C" { ' directive is missing. (Sorry, I forgot to 
mention this in the last email).

Arne


-----Original Message-----
From:	Charles 'Buck' Krasic
Sent:	Saturday, January 06, 2001 12:24 AM
To:	Arne Schirmacher
Cc:	lib...@li...
Subject:	Re: [libdv-dev] Problems with libdv


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

> I have sometimes a coredump when decoding DV data. It happens when
> the camcorder is in fast play or play-backwards mode (hitting the
> wind or rewind key during playing). The decoded image is very
> scrambled (but identical to the camcorder display), but sometimes
> the program crashes. You can probably easily reproduce it using
> Kino's preview window.

I tried for a few minutes to reproduce the problem.  I hit various
combinations of ff and rwd during play.  I didn't get a crash.

> I can also send a short DV file.

I think that would be best.

> Another (easy) problem: the header files installed by `make install`
> won't compile with C++. There is a variable named 'private'
> somewhere, which is a reserved keyword. Also, one header file is
> missing (bitstream.h).

The fixups for this are in libdv CVS.

> Arne

-- Buck

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

Re: [libdv-dev] Quick Makefile tweak

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

Is that without asm/mmx?

I get nearly that, about 15fps, on a 400 MHz P2.

On a 933 MHz P3, I get about 38fps.

-- Buck


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

> On my Althlon 1Ghz, I'm getting 17fps for pond.dv. (Display is an old nVidia TNT)

[libdv-dev] Quick Makefile tweak

[Scott F. J. <sc...@fl...>]

I haven't been able to compile libdv for a couple of weeks, but
just installed Mandrake 7.2 and the configure stuff is working just
fine now.

One minor change: dct_block_mmx.S is missing from two lines in
Makefile.in.
After that, I was able to compile both with asm and without!

Also, Mandrake 7.2 comes with SDL 1.1.4, which is below the threshold
required by libdv (1.1.6) I just upgraded to the ones from libsdl.org
(1.1.7)
and seem to be fine.

On my Althlon 1Ghz, I'm getting 17fps for pond.dv.
(Display is an old nVidia TNT)

Curiously, I can't ctrl-C out of playdv.
If I stop it with ctrl-Z and then try to kill %1,
it just starts playing again!


 diff Makefile.in Makefile.in.orig
97c97
< @HOST_X86_TRUE@ASMS = vlc_x86.S quant_x86.S dct_block_mmx.S
idct_block_mmx.S asmoff.h  mmx.h
---
> @HOST_X86_TRUE@ASMS = vlc_x86.S quant_x86.S idct_block_mmx.S asmoff.h  mmx.h
137c137
< @HOS...@YV... rgb.lo vlc_x86.lo quant_x86.lo dct_block_mmx.lo
idct_block_mmx.lo
---
> @HOS...@YV... rgb.lo vlc_x86.lo quant_x86.lo idct_block_mmx.lo

[libdv-dev] [Bug #127731] can't build libdv

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

Bug #127731, was updated on 2001-Jan-06 02:32
Here is a current snapshot of the bug.

Project: Quasar DV Codec
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: can't build libdv

Details: I just checked out libdv and tried to compile it but got these
errors.

make -f Makefile.vanilla
Making gasmoff.d
Making display.d
Making rgbtoyuv.d
Making dct_block_mmx.d
Making idct_block_mmx.d
Making quant_x86.d
quant_x86.S:22: asmoff.h: No such file or directory

....

vlc_x86.o: In function `dv_decode_vlc':
vlc_x86.o(.text+0x0): multiple definition of `dv_decode_vlc'
vlc.o:/usr/local/libdv/vlc.c:352: first defined here
vlc_x86.o: In function `__dv_decode_vlc':
vlc_x86.o(.text+0x84): multiple definition of `__dv_decode_vlc'
vlc.o:/usr/local/libdv/vlc.c:371: first defined here
vlc_x86.o: In function `dv_parse_ac_coeffs_pass0':
vlc_x86.o(.text+0xec): multiple definition of `dv_parse_ac_coeffs_pass0'
parse.o:/usr/local/libdv/parse.c:366: first defined here
vlc_x86.o: In function `dv_parse_video_segment':
vlc_x86.o(.text+0x2d7): multiple definition of `dv_parse_video_segment'
parse.o:/usr/local/libdv/parse.c:429: first defined here
collect2: ld returned 1 exit status
make: *** [playdv] Error 1


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

Re: [libdv-dev] Problems with libdv

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

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

> I have sometimes a coredump when decoding DV data. It happens when
> the camcorder is in fast play or play-backwards mode (hitting the
> wind or rewind key during playing). The decoded image is very
> scrambled (but identical to the camcorder display), but sometimes
> the program crashes. You can probably easily reproduce it using
> Kino's preview window. 

I tried for a few minutes to reproduce the problem.  I hit various
combinations of ff and rwd during play.  I didn't get a crash.

> I can also send a short DV file.

I think that would be best.

> Another (easy) problem: the header files installed by `make install`
> won't compile with C++. There is a variable named 'private'
> somewhere, which is a reserved keyword. Also, one header file is
> missing (bitstream.h).

The fixups for this are in libdv CVS.

> Arne

-- Buck

[libdv-dev] Kino 0.32 available

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

The new version can be downloaded, as usual, from http://www.schirmacher.de/arne/kino .

New features (besides some minor bug fixes):

It has some preliminary support for Xv (there is still much room for improvement), and it now uses the latest library version of libdv.

Arne

[libdv-dev] Problems with libdv

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

I have sometimes a coredump when decoding DV data. It happens when the 
camcorder is in fast play or play-backwards mode (hitting the wind or 
rewind key during playing). The decoded image is very scrambled (but 
identical to the camcorder display), but sometimes the program crashes. You 
can probably easily reproduce it using Kino's preview window. I can also 
send a short DV file.

Another (easy) problem: the header files installed by `make install` won't 
compile with C++. There is a variable named 'private' somewhere, which is a 
reserved keyword. Also, one header file is missing (bitstream.h).

Arne