libdv-dev

[libdv-dev] [Patch #103780] encoder and ppmqscale improvements

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

Patch #103780 has been updated. 

Project: libdv
Category: None
Status: Open
Submitted by: schlaile
Assigned to : nobody
Summary: encoder and ppmqscale improvements

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

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

[libdv-dev] PAL is broken in current version

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

Hi,

due to a small typo in dv.c PAL decoding is broken.
Makefile.vanilla should be changed too.


-- 

mfg

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

[libdv-dev] [Bug #131581] Initializating multiple dv_decoder_t objects fails

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

Bug #131581, was updated on 2001-Feb-08 09:53
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: heroines
Assigned to : nobody
Summary: Initializating multiple dv_decoder_t objects fails

Details: Initializating multiple dv_decoder_t objects fails due to
recursive math.  Before initializing the codec you need to lock out all the
recursive initialization routines with something like this:

static int dv_initted = 0;

void dv_init(dv_decoder_t *dv) {
#if ARCH_X86
  dv->use_mmx = mmx_ok(); 
#endif
if(!dv_initted)
{
  weight_init();
  dct_init();
  dv_dct_248_init();
  dv_construct_vlc_table();
  dv_parse_init();
  dv_place_init();
}

  dv_quant_init (dv);

if(!dv_initted)
{
  dv_rgb_init();
  dv_YUY2_init();
  dv_YV12_init();
}
  dv_initted = 1;

} /* dv_init */


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

[libdv-dev] [Bug #131580] Crash + chopped audio

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

Bug #131580, was updated on 2001-Feb-08 09:48
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: heroines
Assigned to : nobody
Summary: Crash + chopped audio

Details: The test stream

heroinewarrior.com/test.dv

crashes playdv and produces chopped audio.  This stream is from a JVC
camcorder.

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

[libdv-dev] libdv 0.4 release

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

I've just finished going through the various patches submitted while I
was away last week.  They're substantial enough that I cut a new
release (0.4).

-- Buck

[libdv-dev] Re: Trouble compiling...

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

Hi Scott,

I've been out of town for the last week.

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

> I'm trying to recompile libdv on an SGI, as I've got some files I
> want to convert to frames.

> So much time has gone into optimizing libdv for intel architecture
> that I'm having all sorts of trouble with it under IRIX. Some things
> I can patch, but others I'm at a loss for. There are two basic
> categories of problems:

>   * Compiler restrictions

Yes, I have been liberal in spots of code, assuming that we are using
gcc.  I used a number of gcc specific language extensions.   

>   * ARCH_X86 mmx and asm restrictions.

> For example, I have no knowledge of the syntax used for table
> initialization in vlc.c. This certainly isn't ANSI-C, and puts a
> severe restriction on the compilers that can be used for libdv.
> I don't even know what to do to convert this syntax to "C".
> (This is the show-stopper for me, as I don't know how to proceed.)

I guess you figured this out, but it's a gcc specific extension.  

> Hints like: __attribute__ ((aligned (8))) only apply to specific
> compilers. I've begun to wrap these with:
>   #if HAVE_GCC
>   #define ALIGN8 __attribute__ ((aligned (8)))
>   #define ALIGN32 __attribute__ ((aligned (32)))
>   #else
>   #define ALIGN8
>   #define ALIGN32
>   #endif // HAVE_GCC
> This makes the alignment hints invisible under non-gcc.

> There are lots of places where mmx and asm code is being used
> with no alternative. For example,
>   idct_248.c:  the "fixed_multiply"
>   should be in a #if ARCH_X86 block with an alternative.
>   I can guess that the solution is (a * b) >> 16, but that
>   assumes that you're doing 16.16 fixed. There's no comment to that fact
>   at the head of the routine, and I don't know x86 asm.

Whoops.  You're right.  That needs comments, and should have a C version.

The opcode in question, imull, is multiplying two 32 bit values.  The
upper 32 bits of the 64 bit product are the result.  

>   dct.c:  mmx code should be similarly blocked off.

> I'm going to try to get the code a little less gcc/x86 centric at home
> tonight. If I've any patches, I'll send them in. If you could help
> explain
> vlc.c tables, I'd appreciate it.

Sorry I couldn't be much help as I was away.  

I see you've submitted a patch, and I'll take a look at it now.

> Thanks,

> Scott

-- Buck

[libdv-dev] [Patch #103580] Small modifications for non-gcc, non-x86 compilation

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

Patch #103580 has been updated. 

Project: libdv
Category: None
Status: Open
Submitted by: nobody
Assigned to : nobody
Summary: Small modifications for non-gcc, non-x86 compilation

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

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

[libdv-dev] [Patch #103569] various encoder fixes and improvements

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

Patch #103569 has been updated. 

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

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

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

[libdv-dev] Patch for non-gcc non-x86 architectures

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

This patch contains numerous small modifications to libdv
to get it closer to a point where it can compile on non-x86
architectures with other than gcc compilers.

I have a use for non-realtime software decoding at high quality,
extracting DV into images, and I'd like to be able to do this
under IRIX on an SGI.

The changes are in two broad categories:
  * GCC-specific code
  * x86 specific code

In the first category, I've added some defines in dv_types.h like:
  #define ALIGN32 __attribute__ ((aligned (32)))
and used the new ALIGN32 define elsewhere in the code.
For non_gcc, these are just blanked out:
  #define ALIGN32
so that the compiler ignores them.

There were some cases where the word "class" was being used as
a variable name. I've changed these to "klass" so that they
don't conflict with reserved word "class."

There was a typo in parse.c where a "dv->std" was mistyped as
"dv->system."

All calls to calloc are now cast properly. Some compilers won't assign
from void *.

The compact syntax for setting arrays:
  [0 ... 5] = -1,
is not supported everywhere. The biggest place containing these is in
vlc.c
I "unrolled" these settings and placed:
#if ROLLED
#else
#endif
around the current and new versions. The unrolled ones are long and
ugly, but
compile easier on other platforms.

--Scott

[libdv-dev] just a test

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

are the archives working yet?

Re: [libdv-dev] Re: libdv problems

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

On Son, 21 Jan 2001, you wrote:
> Marc Lavallée <od...@vi...> writes:
> 
> > I got this message when I tried playdv with the pond.dv example:
> > Xv: (ERROR) no adaptor found! 
Thats the real error. If there is no adaptor than we can do nothing
neither with Xv nor with SDL (based in a way on Xv).
For Nvidia cards it is nesscessary to get thier binary only drivers
to get some more HW features. For other cards it is important to load
the right modules. Uhps but misssing modules are indicated by
... Xv extension missing. So perhaps card memory related (see SFJs msg)
or try to disable DRI (if enabled).

-- 

mfg

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

Re: [libdv-dev] Re: libdv problems

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

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

> The Matrox G200 has two overlay modes, one is name "texturedvideo"
> (which actually isn't a real overlay, but uses the same YUV data. It
> also has more ports than the real overlay mode). This one works much
> better than the original overlay. When using the real overlay in
> 24bpp mode, the image flickers and is snowy.

Cool.  Sounds like they are using 3D HW textures with YUV color space.

My understanding is that many cards support YUV textures, but the
drivers and APIs don't exist to access them under Linux.  OpenGL
pretty much assumes RGB.  There exists extensions, but I think they
are only implemented on some SGI machines.

I'd be cursious to know if Direct3D supports it under windows.

> Maybe there is a similar option for the nVidia driver?

> Arne

My machine at work has nVidia GeForce2 GTS, and it looks to support
just the regular "real" overlay.  No YUV textures.

-- Buck

RE: [libdv-dev] Re: libdv problems

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

The Matrox G200 has two overlay modes, one is name "texturedvideo" (which 
actually isn't a real overlay, but uses the same YUV data. It also has more 
ports than the real overlay mode). This one works much better than the 
original overlay. When using the real overlay in 24bpp mode, the image 
flickers and is snowy.

Maybe there is a similar option for the nVidia driver?

Arne

-----Original Message-----
From:	Scott F. Johnston
Sent:	Sunday, January 21, 2001 6:53 PM
To:	lib...@li...
Subject:	Re: [libdv-dev] Re: libdv problems

I've had similar problems and was frustrated because I knew that my
driver supported Xv and SDL. (I can write my own SDL programs, but
I couldn't get playdv to work.)

I have an nVidia TNT running nVidia accellerated drivers.

It turns out that my 16Mb card does not have enough memory for
overlay planes when I'm displaying at 1280x1024 and 24bpp.
Since the requirement for Xv and SDL is tied to using
an overlay, when the overlay can't be alloc'd it bombs.

(Strangely, this is true even when I set my SDL_VIDEODRIVER to aalib.)

If you think your card should work, but it is an older card with < 32Mb
of memory, try adjusting your XF86Config to disable higher resolutions.
(Including virtual desktop).
When I set my display to 1024x768@16bpp I started getting better
results out of my SDL programs.

We should be able to get a bit better error checking in libdv to
warn about these conditions. We can also offer the use of SDL
even when hardware overlays aren't available, it just won't be
as speedy.
There could also be some improvements to SDL libraries, as when you put
the machine in fullscreen mode for video, more HW memory should be
available.

--S


Charles 'Buck' Krasic wrote:

>
> > I use XFree86 4.01, and support for Xv is compiled.
>
> This is usually an indication that the XFree86 driver for your
> graphics chipset does not support the Xv extension; either because the
> hardware doesn't support overlay, or because XFree86 driver for the
> chipset hasn't implented Xv yet.  Note that this is different from
> whether XFree86 server supports the Xv extension (yours does).
>
> What type of graphics adaptor do you have?
>

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

Re: [libdv-dev] Re: libdv problems

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

I've had similar problems and was frustrated because I knew that my
driver supported Xv and SDL. (I can write my own SDL programs, but
I couldn't get playdv to work.)

I have an nVidia TNT running nVidia accellerated drivers.

It turns out that my 16Mb card does not have enough memory for
overlay planes when I'm displaying at 1280x1024 and 24bpp.
Since the requirement for Xv and SDL is tied to using
an overlay, when the overlay can't be alloc'd it bombs.

(Strangely, this is true even when I set my SDL_VIDEODRIVER to aalib.)

If you think your card should work, but it is an older card with < 32Mb
of memory, try adjusting your XF86Config to disable higher resolutions.
(Including virtual desktop).
When I set my display to 1024x768@16bpp I started getting better
results out of my SDL programs.

We should be able to get a bit better error checking in libdv to
warn about these conditions. We can also offer the use of SDL
even when hardware overlays aren't available, it just won't be
as speedy.
There could also be some improvements to SDL libraries, as when you put
the machine in fullscreen mode for video, more HW memory should be
available.

--S


Charles 'Buck' Krasic wrote:

> 
> > I use XFree86 4.01, and support for Xv is compiled.
> 
> This is usually an indication that the XFree86 driver for your
> graphics chipset does not support the Xv extension; either because the
> hardware doesn't support overlay, or because XFree86 driver for the
> chipset hasn't implented Xv yet.  Note that this is different from
> whether XFree86 server supports the Xv extension (yours does).
> 
> What type of graphics adaptor do you have?
>

[libdv-dev] Re: libdv problems

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

Marc Lavallée <od...@vi...> writes:

> I got this message when I tried playdv with the pond.dv example:
> Xv: (ERROR) no adaptor found! 

> It plays at 10 fps with choppy sound.

Playdv has a very simple, it's meant mainly as an example, so it
doesn't do anything clever when the machine is not fast enough.  The
sound is choppy because the video is taking to long to process.

  playdv --disable-video  pond.dv

should give correct sound.

> I use XFree86 4.01, and support for Xv is compiled.

This is usually an indication that the XFree86 driver for your
graphics chipset does not support the Xv extension; either because the
hardware doesn't support overlay, or because XFree86 driver for the
chipset hasn't implented Xv yet.  Note that this is different from
whether XFree86 server supports the Xv extension (yours does).

What type of graphics adaptor do you have?

> Also, I got no SDL support; here's the configure message:
> checking for SDL in -lSDL_Init... no
> I use the latest 1.1.7 SDL libs.

There is a mistake in configure.in.  The fix is in CVS.  The
corresponding patch is attached.  Note that without Xv, SDL will not
help.

-- Buck

diff -u libdv/configure.in:1.10 libdv/configure.in:1.11
--- libdv/configure.in:1.10	Sat Jan 20 13:20:51 2001
+++ libdv/configure.in	Sat Jan 20 21:41:40 2001
@@ -110,15 +110,12 @@
 ])
 
 if $use_sdl; then
-	AC_CHECK_LIB(SDL_Init,SDL,
+	AM_PATH_SDL(1.1.6,
 	[
-		AM_PATH_SDL(1.1.6,
-		[
-			AC_DEFINE(HAVE_SDL) 
-			LIBS="$LIBS $SDL_LIBS" 
-			CFLAGS="$CFLAGS $SDL_CFLAGS"
-	 	])
-	])
+		AC_DEFINE(HAVE_SDL) 
+		LIBS="$LIBS $SDL_LIBS" 
+		CFLAGS="$CFLAGS $SDL_CFLAGS"
+ 	])
 fi
 
 if $use_xv; then

[libdv-dev] [Patch #103341] made encode finally work (added audio support!)

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

Patch #103341 has been updated. 

Project: libdv
Category: None
Status: Open
Submitted by: schlaile
Assigned to : nobody
Summary: made encode finally work (added audio support!)

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

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

[libdv-dev] Re: porting quicktime for linux to linuxPPC

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

By default libdv builds with x86 assembly code, including MMX,
versions of some of its algorithms.  

It can be built using only C, by adjusting the Makefile.

The build process of current libdv release uses the GNU "autotools"
(autoconf, automake, libtool, etc.).  Using the new build, it should
automatically avoid x86 assembly on non-x86 platorms.

The version of libdv in the released quicktime for linux (qt4l) does
not include those changes though.  

I've only recently released libdv in what I consider the first "beta".
It would be nice to find a way to reconcile qt4l with the released
libdv.  

-- Buck

ps Performance of the C version of libdv is guaranteed to be extremely
   slow right now, as we don't include a fast C idct (88).  It will be
   easy to incorporate one of those.

Jan Duennweber <Jan...@in...> writes:

> i'ld like to run quicktime for linux on my linux power pc
> system. Unfortunately i didn't manage to compile the sources, so i
> looked into them and there i found the problem :

> 	..."pushf\n\t"
> 	   "popl %%eax\n\t"
> 	   "movl %%eax, %%ecx\n\t"...

> in quicktime/libdv/ there is some assembly language code for intel
> CPUs. my question : are theese parts of the DV decoder needed to run
> quicktime ? or is there a possiblity to create useable quicktime
> libraries without the parts written in assembly language ?  any help
> greatly appreciated...

> best regards

>     Jan Duennweber

[libdv-dev] Kino 0.34 released

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

New version of Kino available: download from http://www.schirmacher.de/arne/kino/kino_0.34.tar.gz .

It contains patches for new features (saving one single frame as an image file) and bugfixes (NTSC and Xv related problems).

I have set up an own mailing list for Kino. You can subscribe for it at this URL:
http://lists.sourceforge.net/lists/listinfo/kino-dev .
Most Kino discussions do not really fit into the libdev or ieee1394 mailing lists anymore, so please use the new list.

The complete archives of the Kino discussion list (all five postings) can be accessed at:

http://www.geocrawler.com/lists/3/SourceForge/7811/0/ .

Please consider contributing code to Kino.

Arne

[libdv-dev] Re: great job !!!

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

That was the fix to 12-bit sound.  

It was one of those things were I had looked at the code over and over
and just couldn't see the problem.  Then I explained it briefly to
Erik, and poof! the solution was obvious. 

-- Buck

[libdv-dev] great job !!!

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

Hi Buck,

I just think that your last modifications to libdv did improve it quiet well.
It's the first time I could get some suitable sound from my *.dv files out of
my MB (onboard esssolo1 chip) with earphones.


-- 

mfg

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

Re: [libdv-dev] Progressive scan, 4:3 vs 16:9

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

I've incorporated the patch.  Thanks.

I havn't checked into Arne's format problem yet.

-- Buck

[libdv-dev] Progressive scan, 4:3 vs 16:9

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

Hi,

my camera Sony TRV900 has a weired understanding of progressive scan mode.
With prog scan enabled it records only at 12.5 frames/sec. Picture looks jerky
and on every second frame the the FRAME CHANGED bit of vaux packed is not set.
An example for this (4 frames) is at:
  http://home.snafu.de/lucke/dv.prog-scan4f.dv

I added some code to evaluate this and some other (format 4:3 vs. 16:9) flags
of available vaux packets. A patch for this is available:
  http://home.snafu.de/lucke/libdv.vaux.patch

Detection of 50/60 Hz system changed too. This may solve Arne's reported
weired dv format too?

-- 

mfg

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

[libdv-dev] HAVELIB_POPT etc...

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

Hi,

there are still some issues with compiling.

- file util.h: missing #if HAVE_LIBPOPT
- file audio.c: missing #include <stdio.h>
  Is this to be included always or only if HAVE_CONFIG_H is undefined?

Thanks for hint (in source) how to get LIBPOPT. 

Another point: Bitfield definition in structs like in 'dv_aaux_as_pc2_t'
are to my knowledge machine/compiler dependent. 'cdrecord' has
different bitfield type definitions for intel and motorola cpus in its
SCSI transport layer.

-- 

mfg

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

[libdv-dev] Got encode to work !

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

Partially ! Checked out latest from cvs today and built playdv & encode.
playdv now shows pond.dv again but the sound has gone very choppy and
weird.

I created a series of 720*576 ppms and used encode to to make a 2 sec
dv. It worked, but the video has a serious quilting effect when watched
using playdv. You might recognise it from the interference x
screensaver, from which I hacked code to generate these pictures. I have
not had time to watch intf.dv on some other platform yet.

DV movie here (~ 7 Mb)
http://zelda.spray.se/~lukas/intf.dv

A sample image from the encode input is here
http.//zelda.spray.se/~lukas/intf.jpg.

A screenshot of playdv playing the "encoded" video is here,
http://zelda.spray.se/~lukas/playdv.jpg

/Lukas

[libdv-dev] [Patch #103237] Patch to allow standard version of libdv to work.

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

Patch #103237 has been updated. 

Project: libdv
Category: None
Status: Open
Submitted by: mikestump
Assigned to : nobody
Summary: Patch to allow standard version of libdv to work.

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

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