libdv-dev

Re: [libdv-dev] Re: libdv for AMD64

[Dean K. <kol...@qw...>]

I can't reproduce the linking problem. dv_peek_vlc is an inlined function 
in vlc.h, so it should be compiled into each .o that calls it, and not need 
to be linked. Something must be preventing the compiler from inlining 
dv_peek_vlc into dovlc.o, but I don't see how that can happen. I don't 
think it's related to the x86-64 code.

I double-checked that I can download libdv-0.104.tar.gz, apply 
libdv_reloc_fixes.tar.bz2, and do the build.

I fixed the assembler warnings in vlc_x86_64.S late last night, but that's 
just cosmetic.

At 09:13 AM 12/12/2004, sean darcy wrote:
>Dean Kolosiek wrote:
>
>>Oops, wrong file name. Try 
>>http://www.users.qwest.net/~kdean6/libdv_reloc_fixes.tar.bz2
>
>Still no joy.
>
>I put encode_x86_64.S, idct_block_mmx_x86_64.S, quant_x86_64.S  and 
>vlc_x86_64.S into libdv, overwriting the existing files.
>
>Then:
>
>if /bin/sh ../libtool --silent --mode=compile --tag=CC gcc -DHAVE_CONFIG_H 
>-I. -I. -I..     -fPIC -Wall -MT enc_output.lo -MD -MP -MF 
>".deps/enc_output.Tpo" -c -o enc_output.lo enc_output.c; \
>then mv -f ".deps/enc_output.Tpo" ".deps/enc_output.Plo"; else rm -f 
>".deps/enc_output.Tpo"; exit 1; fi
>/bin/sh ../libtool --silent --mode=compile gcc  -fPIC -c -o vlc_x86_64.lo 
>vlc_x86_64.S
>vlc_x86_64.S: Assembler messages:
>vlc_x86_64.S:392: Warning: indirect call without `*'
>vlc_x86_64.S:609: Warning: indirect call without `*'
>vlc_x86_64.S:644: Warning: indirect jmp without `*'
>/bin/sh ../libtool --silent --mode=compile gcc  -fPIC -c -o 
>quant_x86_64.lo quant_x86_64.S
>/bin/sh ../libtool --silent --mode=compile gcc  -fPIC -c -o 
>idct_block_mmx_x86_64.lo idct_block_mmx_x86_64.S
>/bin/sh ../libtool --silent --mode=compile gcc  -fPIC -c -o 
>dct_block_mmx_x86_64.lo dct_block_mmx_x86_64.S
>/bin/sh ../libtool --silent --mode=compile gcc  -fPIC -c -o 
>rgbtoyuv_x86_64.lo rgbtoyuv_x86_64.S
>/bin/sh ../libtool --silent --mode=compile gcc  -fPIC -c -o 
>encode_x86_64.lo encode_x86_64.S
>/bin/sh ../libtool --silent --mode=compile gcc  -fPIC -c -o 
>transpose_x86_64.lo transpose_x86_64.S
>/bin/sh ../libtool --silent --mode=link --tag=CC gcc  -fPIC -Wall   -o 
>libdv.la -rpath /lib -version-info 4:2:0 dv.lo dct.lo idct_248.lo 
>weighting.lo quant.lo vlc.lo place.lo parse.lo bitstream.lo YUY2.lo 
>YV12.lo rgb.lo audio.lo util.lo encode.lo headers.lo enc_input.lo 
>enc_audio_input.lo enc_output.lo vlc_x86_64.lo quant_x86_64.lo 
>idct_block_mmx_x86_64.lo dct_block_mmx_x86_64.lo rgbtoyuv_x86_64.lo 
>encode_x86_64.lo transpose_x86_64.lo  -lm
>if gcc -DHAVE_CONFIG_H -I. -I. -I..     -fPIC -Wall -MT dovlc.o -MD -MP 
>-MF ".deps/dovlc.Tpo" -c -o dovlc.o dovlc.c; \
>then mv -f ".deps/dovlc.Tpo" ".deps/dovlc.Po"; else rm -f 
>".deps/dovlc.Tpo"; exit 1; fi
>/bin/sh ../libtool --silent --mode=link --tag=CC gcc  -fPIC -Wall   -o 
>dovlc  dovlc.o libdv.la -lm
>dovlc.o(.text+0x1e0): In function `main':
>: undefined reference to `dv_peek_vlc'
>collect2: ld returned 1 exit status
>make[3]: *** [dovlc] Error 1
>
>
>sean
>
>

Re: [libdv-dev] Re: libdv for AMD64

[sean d. <sea...@ho...>]

Dean Kolosiek wrote:

>Oops, wrong file name. Try 
>http://www.users.qwest.net/~kdean6/libdv_reloc_fixes.tar.bz2

Still no joy.

I put encode_x86_64.S, idct_block_mmx_x86_64.S, quant_x86_64.S  and 
vlc_x86_64.S into libdv, overwriting the existing files.

Then:

if /bin/sh ../libtool --silent --mode=compile --tag=CC gcc -DHAVE_CONFIG_H 
-I. -I. -I..     -fPIC -Wall -MT enc_output.lo -MD -MP -MF 
".deps/enc_output.Tpo" -c -o enc_output.lo enc_output.c; \
then mv -f ".deps/enc_output.Tpo" ".deps/enc_output.Plo"; else rm -f 
".deps/enc_output.Tpo"; exit 1; fi
/bin/sh ../libtool --silent --mode=compile gcc  -fPIC -c -o vlc_x86_64.lo 
vlc_x86_64.S
vlc_x86_64.S: Assembler messages:
vlc_x86_64.S:392: Warning: indirect call without `*'
vlc_x86_64.S:609: Warning: indirect call without `*'
vlc_x86_64.S:644: Warning: indirect jmp without `*'
/bin/sh ../libtool --silent --mode=compile gcc  -fPIC -c -o quant_x86_64.lo 
quant_x86_64.S
/bin/sh ../libtool --silent --mode=compile gcc  -fPIC -c -o 
idct_block_mmx_x86_64.lo idct_block_mmx_x86_64.S
/bin/sh ../libtool --silent --mode=compile gcc  -fPIC -c -o 
dct_block_mmx_x86_64.lo dct_block_mmx_x86_64.S
/bin/sh ../libtool --silent --mode=compile gcc  -fPIC -c -o 
rgbtoyuv_x86_64.lo rgbtoyuv_x86_64.S
/bin/sh ../libtool --silent --mode=compile gcc  -fPIC -c -o encode_x86_64.lo 
encode_x86_64.S
/bin/sh ../libtool --silent --mode=compile gcc  -fPIC -c -o 
transpose_x86_64.lo transpose_x86_64.S
/bin/sh ../libtool --silent --mode=link --tag=CC gcc  -fPIC -Wall   -o 
libdv.la -rpath /lib -version-info 4:2:0 dv.lo dct.lo idct_248.lo 
weighting.lo quant.lo vlc.lo place.lo parse.lo bitstream.lo YUY2.lo YV12.lo 
rgb.lo audio.lo util.lo encode.lo headers.lo enc_input.lo enc_audio_input.lo 
enc_output.lo vlc_x86_64.lo quant_x86_64.lo idct_block_mmx_x86_64.lo 
dct_block_mmx_x86_64.lo rgbtoyuv_x86_64.lo encode_x86_64.lo 
transpose_x86_64.lo  -lm
if gcc -DHAVE_CONFIG_H -I. -I. -I..     -fPIC -Wall -MT dovlc.o -MD -MP -MF 
".deps/dovlc.Tpo" -c -o dovlc.o dovlc.c; \
then mv -f ".deps/dovlc.Tpo" ".deps/dovlc.Po"; else rm -f ".deps/dovlc.Tpo"; 
exit 1; fi
/bin/sh ../libtool --silent --mode=link --tag=CC gcc  -fPIC -Wall   -o dovlc 
  dovlc.o libdv.la -lm
dovlc.o(.text+0x1e0): In function `main':
: undefined reference to `dv_peek_vlc'
collect2: ld returned 1 exit status
make[3]: *** [dovlc] Error 1


sean

Re: [libdv-dev] Re: libdv for AMD64

[Dean K. <kol...@qw...>]

Oops, wrong file name. Try 
http://www.users.qwest.net/~kdean6/libdv_reloc_fixes.tar.bz2


At 04:30 PM 12/11/2004, sean darcy wrote:
>Dean Kolosiek wrote:
>
>>................................
>>I made some fixes to use the GOT and put them 
>>at >http://www.users.qwest.net/~kdean6/libdv_fixes.tar.bz2 Extract the 
>>files into the libdv subdirectory and rebuild.
>
>Thanks for all the work.
>
>But... Put the encode.c  encode_x86_64.S and quant_x86_64.S files in 
>lbdv-0.104. Rebuilt:
>
>/bin/sh ../libtool --silent --mode=link --tag=CC gcc  -fPIC -Wall   -o 
>libdv.la -rpath /lib -version-info 4:2:0 dv.lo dct.lo idct_248.lo 
>weighting.lo quant.lo vlc.lo place.lo parse.lo bitstream.lo YUY2.lo 
>YV12.lo rgb.lo audio.lo util.lo encode.lo headers.lo enc_input.lo 
>enc_audio_input.lo enc_output.lo vlc_x86_64.lo quant_x86_64.lo 
>idct_block_mmx_x86_64.lo dct_block_mmx_x86_64.lo rgbtoyuv_x86_64.lo 
>encode_x86_64.lo transpose_x86_64.lo  -lm
>/usr/bin/ld: .libs/vlc_x86_64.o: relocation R_X86_64_PC32 against 
>`dv_vlc_class_index_mask' can not be used when making a shared object; 
>recompile with -fPIC
>/usr/bin/ld: final link failed: Bad value
>collect2: ld returned 1 exit status
>make[3]: *** [libdv.la] Error 1
>
>No joy.
>
>sean
>
>

Re: [libdv-dev] Re: libdv for AMD64

[sean d. <sea...@ho...>]

Dean Kolosiek wrote:

>................................
>I made some fixes to use the GOT and put them at 
> >http://www.users.qwest.net/~kdean6/libdv_fixes.tar.bz2 Extract the files 
>into the libdv subdirectory and rebuild.

Thanks for all the work.

But... Put the encode.c  encode_x86_64.S and quant_x86_64.S files in 
lbdv-0.104. Rebuilt:

/bin/sh ../libtool --silent --mode=link --tag=CC gcc  -fPIC -Wall   -o 
libdv.la -rpath /lib -version-info 4:2:0 dv.lo dct.lo idct_248.lo 
weighting.lo quant.lo vlc.lo place.lo parse.lo bitstream.lo YUY2.lo YV12.lo 
rgb.lo audio.lo util.lo encode.lo headers.lo enc_input.lo enc_audio_input.lo 
enc_output.lo vlc_x86_64.lo quant_x86_64.lo idct_block_mmx_x86_64.lo 
dct_block_mmx_x86_64.lo rgbtoyuv_x86_64.lo encode_x86_64.lo 
transpose_x86_64.lo  -lm
/usr/bin/ld: .libs/vlc_x86_64.o: relocation R_X86_64_PC32 against 
`dv_vlc_class_index_mask' can not be used when making a shared object; 
recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[3]: *** [libdv.la] Error 1

No joy.

sean

Re: [libdv-dev] Re: libdv for AMD64

[Dean K. <kol...@qw...>]

I changed to ld 2.15.92.0.2, which is in Fedora Core 3, and reproduced the 
problem.

As I understand it, x86-64 shared libraries cannot use absolute addresses 
in the instructions, because the library may be shared between multiple 
executables. Also, most rip-relative instructions can only use a 32-bit 
offset. Therefore in x86-64 shared libraries, when accessing an address in 
another .o, you have to go through the Global Offset Table. The computed 
address has to be 64 bits, a 32 bit offset doesn't work between shared .o 
files. The new linker is enforcing this. For libdv, the error messages are 
correct. Within a .o, smaller than 2 GB, rip-relative addresses can be used 
without going through the GOT.

I found a new version of the ABI at 
http://ftp.lug.ro/suse/people/matz/ABI/abi-095.pdf with an expanded section 
3.5 with position independent code examples.

I made some fixes to use the GOT and put them at 
http://www.users.qwest.net/~kdean6/libdv_fixes.tar.bz2 Extract the files 
into the libdv subdirectory and rebuild.

RE: [libdv-dev] libdv-0.104 build fails on x86_64

[sean d. <sea...@ho...>]

I tried --disable-asm. i got:

/bin/sh ../libtool --silent --mode=link --tag=CC gcc  -fPIC -Wall   -o dovlc 
  dovlc.o libdv.la -lm
dovlc.o(.text+0x1e0): In function `main':
: undefined reference to `dv_peek_vlc'
collect2: ld returned 1 exit status
make[3]: *** [dovlc] Error 1
make[3]: Leaving directory `/usr/src/redhat/BUILD/libdv-0.104/libdv'
make[2]: *** [all] Error 2


sean

Re: [libdv-dev] Re: libdv for AMD64

[Dean K. <kol...@qw...>]

What version of ld are you using?


I found the following change to ld in May. The patch seems to be the 
difference.

http://sources.redhat.com/ml/binutils/2004-05/msg00593.html



I'm looking for documentation on relocations and writing assembler for 
shared libraries.I found a reference that suggests R_X86_64_PC32 is wrong 
because it is only 32 bits, and a recently added R_X86_64_PC64 relocation.

RE: [libdv-dev] libdv-0.104 build fails on x86_64

[Dan D. <da...@de...>]

On Wed, 2004-12-08 at 11:35 -0500, sean darcy wrote:
> I configured --disable-mmx, but this doesn't show up  in configure --help. 
> Does it do anything? If not,  maybe this is just the generic problem of 
> x86_64 having trouble with mmx? Is it possible to disable mmx?

No, only --disable-asm is valid, which includes mmx.

Re: [libdv-dev] Re: libdv for AMD64

[Roman S. <rv...@su...>]

On Wed, Dec 08, 2004 at 03:34:24AM -0700, Dean Kolosiek wrote:
> I'm pretty sure R_X86_64_PC32 is correct for 64 bit PIC code. In fact, I 
> had to change these same instructions, the ones with (%rip), to get it to 
> link on my machine. I was getting the same error message, but for 
> R_X86_64_32S.
> 
> I'm new to libtool, so I can't help if that's the problem.
> 
> I think -fPIC is for the compiler to generate position independent code, 
> and won't affect the assembler.
> 
> I'm using Fedora Core 2 x86-64, gcc 3.3.3, ld 2.15.90.0.3, libtool 1.5.6
> 
> All I can think of now is that the linker is confused, as if it thinks it 
> is linking 32 bit code or something, or too old to handle R_X86_64_PC32 . 
> 32 bit code used a different relocation mode.

  We have the very same issue if ffmpeg. Here's my evaluation of the problem:

===============================================================================
From: Roman Shaposhnik
To: ffmpeg-devel
Subject: AMD64 build

On Fri, Nov 05, 2004 at 04:02:57PM -0800, klsat17 wrote:
> Hey guys,
> 
> I searched the archives for this problem, but couldn't find that anyone has 
> run across it.   After running 
> ./configure --with-x11libdir=/usr/X11R6/lib64/ --libdir=/usr/lib64 
> --enable-shared
> 
> and then typing make, I get the error listed below.  I'm a newbie when it 
> comes to this whole I-want-to-copy-DVDs effort and have discovered so many 
> different packages and libraries which must be installed that I am 
> particularly confused.  I also compiled and installed the xvidcore-1.0.2 
> (with the -fPIC flag) package separately.  With regard to the -fPIC stuff, I 
> tried forcing this as a CFLAG, but it doesn't seem to make any difference.  
> Can anyone shed any light on this?  

  -fPIC lets you cure the original problem (the one you quoted) but
  it leaves you in the open with the problems in the following three
  files:
        i386/simple_idct_mmx.o
	i386/motion_est_mmx.o
	i386/dsputil_mmx.o

  And this really opens the floodgate for the usual "bash-the-gcc" sort
  of feast. Here's the deal, take a look at this code:

  $ cat test.c
  static const uint64_t ff_pw_3 __attribute__ ((aligned(8))) = 0x0003000300030003ULL;
  void bar (void)
  {
    asm ("pmullw ff_pw_3, %%mm5" ::);
  }

  Now, when this code gets compiled on x86, it generates the usual relocation
  of R_386_32 for the ff_pw_3 symbol and later, since this symbol is local
  anyway, linker happily accepts R_386_32 and patches the real offset in.

  Now, when compiled on AMD64 it generates R_X86_64_PC32 relocation
  which seem like the right thing to do, but later linker gets confused
  and doesn't want to patch the real offset in. It is not clear to me
  why the confusion. AFAIK, in this particular case (and especially
  given the absence of the large model) R_X86_64_PC32 should behave
  exactly like R_386_32 does on x86. All in all, it seems to be 
  a linker bug to me.

  Once again -- this is not an issue of *creating* a .text relocation
  in a shared library, but simply an issue of accepting R_X86_64_PC32
  on input, being smart enough to see that we *DO NOT* actually need a 
  relocation and outputting the absolute address into the .so.

  Now, the fact tha GNU ld doesn't want to accept R_X86_64_PC32
  even if there's no need to generate any actual relocation made
  gcc guys *forbid* it when you specify -fPIC (once again, I *DO*
  think this is totally uncalled for, but lets put that aside
  for a moment here). Of course they have no control over the
  verbatim stuff you put in your __asm__ ... hence you need
  to be more specific:
  
  static const uint64_t ff_pw_3 __attribute__ ((aligned(8))) = 0x0003000300030003ULL;
  void bar (void)
  {
    asm ("pmullw %0, %%mm5" : : "m" (ff_pw_3));
  }
 
  And that compiles right of the bat:

  $ cc -shared -fPIC -o test.so test.c
  $ 

  Of course it generates one extra instruction:

      lea .... , %rax
      pmullw (%rax), %mm5

  but that's a different story.

  So, what does it mean for ffmpeg ? Well, at this point I'd rather ask GNU ld
  folks about why ld is not smart enough to recognize this situation.
      
Thanks,
Roman.


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Ffmpeg-user mailing list
Ffm...@li...
https://lists.sourceforge.net/lists/listinfo/ffmpeg-user
===============================================================================

Re: [libdv-dev] [PATCH] dv_encode_timecode_fps

[Roman S. <rv...@su...>]

On Wed, Dec 08, 2004 at 01:30:43PM -0500, Richard Baverstock wrote:
> It's come to my attention that this doesn't perfectly handle drop-frame
> timecode correctly still, but opens the door for it.
> 
> Quote from an email from Phil Rhodes:
> 
> "Just to make this ultra clear, all minutes except tens in DF timecode
> look like this:
> 
> 00:00:59:28 - 00:00:59:29 - 00:01:00:02 - 00:01:00:03

  The way I implemented it in ffmpeg's DV codec is:

          /*
           * LTC drop-frame frame counter drops two frames (0 and 1) every
           * minute, unless it is exactly divisible by 10
           */
          ltc_frame = (c->frames + 2*ct/60 - 2*ct/600) % c->sys->ltc_divisor;

Thanks,
Roman.
 
> Also refer to Adobe's writeup at
> http://www.ledet.com/coolstuff/software/premiere/timecode.pdf - I
> haven't looked it over, but I presume they know what they're doing."
> 
> 
> Patch in a little bit, exams this and next week.
> 
> On Wed, 2004-12-08 at 10:52 -0500, Richard Baverstock wrote:
> > Attached is a patch that adds the function "dv_encode_timecode_fps()" to
> > headers.c and the public api of libdv. The function acts exactly like
> > dv_encode_timecode(), but takes an additional parameter (the frame
> > rate). This allows drop frame/non-drop frame timecodes to be encoded, as
> > well as non-pal or ntsc frame rates such as film.
> > 
> > dv_encode_timecode() is maintained so as not to break the api, and
> > serves as a wrapper to dv_encode_timecode_fps() (with the same behavior
> > as before - 30 fps assumed for NTSC).
> > 
> > write_timecode_13() is modified to take a double parameter instead of an
> > integer to determine the frame rate. In write_subcode_blocks(), 30 fps
> > is again assumed to be the frame rate for ntsc when write_timecode_13()
> > is called.
> > 
> > While this fixes the dv_encode_timecode() issue for non-drop frame
> > timecode, you can see there are some wrong assumptions still in the rest
> > of libdv. I didn't want to delve any further into the library until I
> > got some feedback. In some cases, it will be necessary to change the
> > internal api (write_subcode_blocks() for example will have to take an
> > fps parameter), and the public api (an fps field in dv_encoder_t).
> > 
> > Anyways, with this patch, everything works as before unless you use
> > dv_encode_timecode_fps().
> > 
> > 
> > 
> > 
> > Richard
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev

Re: [libdv-dev] [PATCH] dv_encode_timecode_fps

[Richard B. <ba...@th...>]

It's come to my attention that this doesn't perfectly handle drop-frame
timecode correctly still, but opens the door for it.

Quote from an email from Phil Rhodes:

"Just to make this ultra clear, all minutes except tens in DF timecode
look like this:

00:00:59:28 - 00:00:59:29 - 00:01:00:02 - 00:01:00:03

Also refer to Adobe's writeup at
http://www.ledet.com/coolstuff/software/premiere/timecode.pdf - I
haven't looked it over, but I presume they know what they're doing."


Patch in a little bit, exams this and next week.

On Wed, 2004-12-08 at 10:52 -0500, Richard Baverstock wrote:
> Attached is a patch that adds the function "dv_encode_timecode_fps()" to
> headers.c and the public api of libdv. The function acts exactly like
> dv_encode_timecode(), but takes an additional parameter (the frame
> rate). This allows drop frame/non-drop frame timecodes to be encoded, as
> well as non-pal or ntsc frame rates such as film.
> 
> dv_encode_timecode() is maintained so as not to break the api, and
> serves as a wrapper to dv_encode_timecode_fps() (with the same behavior
> as before - 30 fps assumed for NTSC).
> 
> write_timecode_13() is modified to take a double parameter instead of an
> integer to determine the frame rate. In write_subcode_blocks(), 30 fps
> is again assumed to be the frame rate for ntsc when write_timecode_13()
> is called.
> 
> While this fixes the dv_encode_timecode() issue for non-drop frame
> timecode, you can see there are some wrong assumptions still in the rest
> of libdv. I didn't want to delve any further into the library until I
> got some feedback. In some cases, it will be necessary to change the
> internal api (write_subcode_blocks() for example will have to take an
> fps parameter), and the public api (an fps field in dv_encoder_t).
> 
> Anyways, with this patch, everything works as before unless you use
> dv_encode_timecode_fps().
> 
> 
> 
> 
> Richard

RE: [libdv-dev] libdv-0.104 build fails on x86_64

[sean d. <sea...@ho...>]

Sorry for posting when there's another thread on this topic.

But....... there appear are two mmx related files here:

idct_block_mmx_x86_64.lo

dct_ block_mmx_x86_64.lo

I configured --disable-mmx, but this doesn't show up  in configure --help. 
Does it do anything? If not,  maybe this is just the generic problem of 
x86_64 having trouble with mmx? Is it possible to disable mmx?

sean

[libdv-dev] [PATCH] dv_encode_timecode_fps

[Richard B. <ba...@th...>]

Attached is a patch that adds the function "dv_encode_timecode_fps()" to
headers.c and the public api of libdv. The function acts exactly like
dv_encode_timecode(), but takes an additional parameter (the frame
rate). This allows drop frame/non-drop frame timecodes to be encoded, as
well as non-pal or ntsc frame rates such as film.

dv_encode_timecode() is maintained so as not to break the api, and
serves as a wrapper to dv_encode_timecode_fps() (with the same behavior
as before - 30 fps assumed for NTSC).

write_timecode_13() is modified to take a double parameter instead of an
integer to determine the frame rate. In write_subcode_blocks(), 30 fps
is again assumed to be the frame rate for ntsc when write_timecode_13()
is called.

While this fixes the dv_encode_timecode() issue for non-drop frame
timecode, you can see there are some wrong assumptions still in the rest
of libdv. I didn't want to delve any further into the library until I
got some feedback. In some cases, it will be necessary to change the
internal api (write_subcode_blocks() for example will have to take an
fps parameter), and the public api (an fps field in dv_encoder_t).

Anyways, with this patch, everything works as before unless you use
dv_encode_timecode_fps().




Richard

[libdv-dev] libdv-0.104 build fails on x86_64

[sean d. <sea...@ho...>]

I'm trying to build libdv-0.104 on fedora fc 3 x86_64.

I get  this:

/bin/sh ../libtool --silent --mode=link --tag=CC gcc  -march=athlon64 -fPIC 
-Wall   -o libdv.la -rpath /lib -version-info 4:2:0 dv.lo dct.lo idct_248.lo 
weighting.lo quant.lo vlc.lo place.lo parse.lo bitstream.lo YUY2.lo YV12.lo 
rgb.lo audio.lo util.lo encode.lo headers.lo enc_input.lo enc_audio_input.lo 
enc_output.lo vlc_x86_64.lo quant_x86_64.lo idct_block_mmx_x86_64.lo 
dct_block_mmx_x86_64.lo rgbtoyuv_x86_64.lo encode_x86_64.lo 
transpose_x86_64.lo  -lm
/usr/bin/ld: .libs/vlc_x86_64.o: relocation R_X86_64_PC32 against 
`dv_vlc_class_index_mask' can not be used when making a shared object; 
recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[3]: *** [libdv.la] Error 1
make[3]: Leaving directory `/usr/src/redhat/BUILD/libdv-0.104/libdv'
make[2]: *** [all] Error 2

I've tried

export CFLAGS="-march=athlon64 -fPIC"
./configure --prefix=${_prefix} --without-debug --mandir=%{_mandir} 
--disable-mmx --with-pic

Same result.

gcc-3.4.3

sean

Re: [libdv-dev] Re: libdv for AMD64

[Dean K. <kol...@qw...>]

I'm pretty sure R_X86_64_PC32 is correct for 64 bit PIC code. In fact, I 
had to change these same instructions, the ones with (%rip), to get it to 
link on my machine. I was getting the same error message, but for R_X86_64_32S.

I'm new to libtool, so I can't help if that's the problem.

I think -fPIC is for the compiler to generate position independent code, 
and won't affect the assembler.

I'm using Fedora Core 2 x86-64, gcc 3.3.3, ld 2.15.90.0.3, libtool 1.5.6

All I can think of now is that the linker is confused, as if it thinks it 
is linking 32 bit code or something, or too old to handle R_X86_64_PC32 . 
32 bit code used a different relocation mode.

This is how line 19 gets assembled on my system, and it uses R_X86_64_PC32. 
I used objdump -d -l -S -r vlc_x86_64.o to generate this:

/home/kolosiek/downloads/libdv/libdv-0.103-cvs/libdv/libdv/vlc_x86_64.S:19

         /* note that BITS is left aligned */
         /* klass = dv_vlc_classes[maxbits][(bits & 
(dv_vlc_class_index_mask[maxbits])) >> */
         /*         (dv_vlc_class_index_rshift[maxbits])];  */
/*      xor  %rbp,%rbp */
         lea  dv_vlc_class_index_mask(%rip),%r11            /* use %rip for 
PIC code */
    c:   4c 8d 1d 00 00 00 00    lea    0(%rip),%r11        # 13 
<dv_decode_vlc+0x13>
                         f: 
R_X86_64_PC32        dv_vlc_class_index_mask+0xfffffffffffffffc



At 09:38 PM 12/7/2004, Richard Baverstock wrote:
>Trying to compile the current CVS on a Suse 9.2 opteron system results
>in the following compile error for me:
>
>
>/bin/sh ../libtool --silent --mode=link --tag=CC gcc  -g -O2 -Wall -g
>-o libdv.la -rpath /usr/lib64 -version-info 4:2:0 dv.lo dct.lo
>idct_248.lo weighting.lo quant.lo vlc.lo place.lo parse.lo bitstream.lo
>YUY2.lo YV12.lo rgb.lo audio.lo util.lo encode.lo headers.lo
>enc_input.lo enc_audio_input.lo enc_output.lo vlc_x86_64.lo
>quant_x86_64.lo idct_block_mmx_x86_64.lo dct_block_mmx_x86_64.lo
>rgbtoyuv_x86_64.lo encode_x86_64.lo transpose_x86_64.lo  -lm
>/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.4/../../../../x86_64-suse-linux/bin/ld: 
>.libs/vlc_x86_64.o: relocation R_X86_64_PC32 against `dv_vlc_index_mask' 
>can not be used when making a shared object; recompile with -fPIC
>/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.4/../../../../x86_64-suse-linux/bin/ld: 
>final link failed: Bad value
>collect2: ld returned 1 exit status
>
>
>
>
>I added -fPIC to the CCASFLAGS (and can see it in the compile lines),
>however, it doesn't seem to help.
>
>gcc 3.3.4
>libtool 1.5.8
>
>
>
>On Wed, 2004-10-13 at 07:03 -0400, Dan Dennedy wrote:
> > Thank you. I downloaded it, and will work on making sure it merges
> > nicely into my CVS working copy and test. Then, hopefully we get some
> > others to test.
> >
> > On Tue, 2004-10-12 at 00:32 -0700, Dean Kolosiek wrote:
> > > Hello,
> > >
> > > I ported the assembly language of libdv-0.103 to AMD64. I left a copy 
> of it
> > > at http://www.users.qwest.net/~kdean6/libdv-0.103-AMD64.tar.gz if you 
> want
> > > it. There's no web page for it, just that file, so go directly to it.
> > >
> > > I also found a bug with multi-threading when I ran
> > > enctest.  _dv_prepare_reorder_tables gets called by each thread during
> > > initialization, but it's not written to run multiple times. I got
> > > segmentation faults at random times because the time slicing was random,
> > > but many times it worked fine. I did not try to fix it.
> > >
> > > I created a definition ARCH_X86_64 that parallels ARCH_X86 nearly
> > > everywhere. I added x86_64 to make new routine names and new .S file 
> names.
> > >
> > > Most of the changes were due to pointers changing to 64 bits, and the 
> ABI
> > > changing for AMD64. I used documents at http://www.x86-64.org/ for 
> the ABI
> > > and they have a translation hints page. There were some cases where 
> there
> > > is no equivalent 64 bit instruction to handle 8 bit data, or the ABI 
> calls
> > > for passing parameters in a register that was being used, so it takes 
> a few
> > > more instructions in a few places. Another big change is that 
> relocatable
> > > libraries use a different relocation mechanism on AMD64, so (%rip) is 
> added
> > > to many instructions to generate PC-relative addresses.
> > >
> > > I did not bother translating the use_mmx parts because it is my
> > > understanding that AMD64 chips will always have mmx functionality. This
> > > should be double-checked, and it may not be true for Intel chips.
> > >
> > > I made no attempt to rewrite anything to make use of  AMD64 features 
> like
> > > 64 bit registers.
> > >
> > > It needs more testing before distribution. I've only tested it with 
> enctest
> > > and playdv, and in kino (linking the new code) I played one .avi file 
> made
> > > by grabdv. playdv plays the pond.dv example. I'm not really a video 
> person,
> > > so I don't know how to come up with tests for it. I'm running it on a
> > > Fedora Core 2 x86-64 Opteron system.
> > >
> > > Dean Kolosiek
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> > Use IT products in your business? Tell us what you think of them. Give us
> > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> > http://productguide.itmanagersjournal.com/guidepromo.tmpl
> > _______________________________________________
> > libdv-dev mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libdv-dev
> >

Re: [libdv-dev] Re: libdv for AMD64

[Richard B. <rba...@en...>]

Trying to compile the current CVS on a Suse 9.2 opteron system results
in the following compile error for me:


/bin/sh ../libtool --silent --mode=link --tag=CC gcc  -g -O2 -Wall -g
-o libdv.la -rpath /usr/lib64 -version-info 4:2:0 dv.lo dct.lo
idct_248.lo weighting.lo quant.lo vlc.lo place.lo parse.lo bitstream.lo
YUY2.lo YV12.lo rgb.lo audio.lo util.lo encode.lo headers.lo
enc_input.lo enc_audio_input.lo enc_output.lo vlc_x86_64.lo
quant_x86_64.lo idct_block_mmx_x86_64.lo dct_block_mmx_x86_64.lo
rgbtoyuv_x86_64.lo encode_x86_64.lo transpose_x86_64.lo  -lm
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.4/../../../../x86_64-suse-linux/bin/ld: .libs/vlc_x86_64.o: relocation R_X86_64_PC32 against `dv_vlc_index_mask' can not be used when making a shared object; recompile with -fPIC
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.4/../../../../x86_64-suse-linux/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status




I added -fPIC to the CCASFLAGS (and can see it in the compile lines),
however, it doesn't seem to help.

gcc 3.3.4
libtool 1.5.8



On Wed, 2004-10-13 at 07:03 -0400, Dan Dennedy wrote:
> Thank you. I downloaded it, and will work on making sure it merges
> nicely into my CVS working copy and test. Then, hopefully we get some
> others to test.
> 
> On Tue, 2004-10-12 at 00:32 -0700, Dean Kolosiek wrote:
> > Hello,
> > 
> > I ported the assembly language of libdv-0.103 to AMD64. I left a copy of it 
> > at http://www.users.qwest.net/~kdean6/libdv-0.103-AMD64.tar.gz if you want 
> > it. There's no web page for it, just that file, so go directly to it.
> > 
> > I also found a bug with multi-threading when I ran 
> > enctest.  _dv_prepare_reorder_tables gets called by each thread during 
> > initialization, but it's not written to run multiple times. I got 
> > segmentation faults at random times because the time slicing was random, 
> > but many times it worked fine. I did not try to fix it.
> > 
> > I created a definition ARCH_X86_64 that parallels ARCH_X86 nearly 
> > everywhere. I added x86_64 to make new routine names and new .S file names.
> > 
> > Most of the changes were due to pointers changing to 64 bits, and the ABI 
> > changing for AMD64. I used documents at http://www.x86-64.org/ for the ABI 
> > and they have a translation hints page. There were some cases where there 
> > is no equivalent 64 bit instruction to handle 8 bit data, or the ABI calls 
> > for passing parameters in a register that was being used, so it takes a few 
> > more instructions in a few places. Another big change is that relocatable 
> > libraries use a different relocation mechanism on AMD64, so (%rip) is added 
> > to many instructions to generate PC-relative addresses.
> > 
> > I did not bother translating the use_mmx parts because it is my 
> > understanding that AMD64 chips will always have mmx functionality. This 
> > should be double-checked, and it may not be true for Intel chips.
> > 
> > I made no attempt to rewrite anything to make use of  AMD64 features like 
> > 64 bit registers.
> > 
> > It needs more testing before distribution. I've only tested it with enctest 
> > and playdv, and in kino (linking the new code) I played one .avi file made 
> > by grabdv. playdv plays the pond.dv example. I'm not really a video person, 
> > so I don't know how to come up with tests for it. I'm running it on a 
> > Fedora Core 2 x86-64 Opteron system.
> > 
> > Dean Kolosiek
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev
> 

Re: [libdv-dev] dv_encode_timecode and frame rate

[Dan D. <da...@de...>]

On Tue, 2004-12-07 at 21:58 -0500, Richard Baverstock wrote:
> In dv_encode_timecode() (and elsewhere), NTSC video is assumed to be 30
> fps (non-drop frame). However, NTSC video is actually 29.97 fps
> (drop-frame). This presents a problem, when a program is using 29.97 fps
> internally, and tries to tell dv_encode_timecode to encode a timecode
> based on the current frame number.
> 
> Is there any intention/incentive to expand dv_encode_timecode to other
> frame rates, such as drop-frame (IIRC, DVCAM and DVCPRO allow you to
> select drop-frame or non-drop-frame, and DV is just drop-frame).

Good point, but I have no plans to fix this soon. If you can supply a
patch, it would be much appreciated.

[libdv-dev] dv_encode_timecode and frame rate

[Richard B. <ba...@th...>]

In dv_encode_timecode() (and elsewhere), NTSC video is assumed to be 30
fps (non-drop frame). However, NTSC video is actually 29.97 fps
(drop-frame). This presents a problem, when a program is using 29.97 fps
internally, and tries to tell dv_encode_timecode to encode a timecode
based on the current frame number.

Is there any intention/incentive to expand dv_encode_timecode to other
frame rates, such as drop-frame (IIRC, DVCAM and DVCPRO allow you to
select drop-frame or non-drop-frame, and DV is just drop-frame).

Thanks,
Richard

Re: [libdv-dev] Continuous "audio block/sample failure" with JVC DV camera

[Marko <mar...@hu...>]

On Thu, Dec 02, 2004 at 01:04:51AM -0500, Nathan Kidd wrote:
> Marko M=E4kel=E4 wrote:
> >I have a JVC GR-DVL9600 (PAL), and audio has worked for me, except for=
 some
> >occasional glitches, probably due to errors on the tape.  I've been us=
ing
> >libdv with the 2.4 kernel since 2.4.21 or so.
>=20
> My motherboard only is supported by 2.6, so I unfortunately can't try=20
> 2.4.  But it's good to know it's not a universal JVC thing.  Maybe it's=
=20
> just my model. That would figure. :)

Well, the GR-DVL9600 is pretty old, apparently from early 2000.  It even
features a JLIP connector (RS-232) for importing still pictures.  It was
a display model that I bought around March 2003.

When I last tried the 2.6 kernel in Debian GNU/Linux unstable, I got some
trouble with the loading of modules.  Maybe the support has been improved
by now.  I could give it a try within the next week.  My IEEE-1394 interf=
ace
is a cheap PCI card based on VIA 6306, if I remember correctly.

	Marko

Re: [libdv-dev] Continuous "audio block/sample failure" with JVC DV camera

[Nathan K. <nat...@sp...>]

Ingo Lütkebohle wrote:
> saw pretty much the same problem with a JVC.  Different model, though.
>  Should still be in the list archives.  We replaced the camera with a
> different make ;-)

Similar in that they were audio-related, though I note the errors and 
problem behaviour are quite different.

Buying a new camera wasn't the solution I was hoping for. ;)

-Nathan

> On Wed, 01 Dec 2004 00:58:13 -0500, Nathan Kidd wrote:
> 
>>Hello,
>>
>>Whenever I dump DV from my JVC camera I get continuous lines like:
>>
>>    asf 00:00:00.00 2000-00-00 00:00:00 70 b7 08 12 2/48
>>    ...above repeated 30 times...
>>    # audio block/sample failure for 0 blocks, 60 samples of 1280
>>
>>The resulting audio stream sounds odd, with little breaks in it. (As one
>>might expect if 60 out of every 1280 audio samples were bad.)
> 
> 
> 

Re: [libdv-dev] Continuous "audio block/sample failure" with JVC DV camera

[Nathan K. <nat...@sp...>]

Marko Mäkelä wrote:
> Nathan Kidd wrote:
> > So my questions: Has anyone else experienced this?  Is this a known 
> > problem? Is there any workaround/fix?  Is there any more info I should 
> > supply?
> 
> 
> I have a JVC GR-DVL9600 (PAL), and audio has worked for me, except for some
> occasional glitches, probably due to errors on the tape.  I've been using
> libdv with the 2.4 kernel since 2.4.21 or so.

My motherboard only is supported by 2.6, so I unfortunately can't try 
2.4.  But it's good to know it's not a universal JVC thing.  Maybe it's 
just my model. That would figure. :)

Thanks,

-Nathan

Re: [libdv-dev] Continuous "audio block/sample failure" with JVC DV camera

[<ilu...@gm...>]

Hi,

saw pretty much the same problem with a JVC.  Different model, though.
 Should still be in the list archives.  We replaced the camera with a
different make ;-)

On Wed, 01 Dec 2004 00:58:13 -0500, Nathan Kidd <nat...@ya...> wrote:
> Hello,
> 
> Whenever I dump DV from my JVC camera I get continuous lines like:
> 
>     asf 00:00:00.00 2000-00-00 00:00:00 70 b7 08 12 2/48
>     ...above repeated 30 times...
>     # audio block/sample failure for 0 blocks, 60 samples of 1280
> 
> The resulting audio stream sounds odd, with little breaks in it. (As one
> might expect if 60 out of every 1280 audio samples were bad.)

Re: [libdv-dev] Continuous "audio block/sample failure" with JVC DV camera

[Marko <mar...@hu...>]

Hi Nathan,

> Whenever I dump DV from my JVC camera I get continuous lines like:
> 
>    asf 00:00:00.00 2000-00-00 00:00:00 70 b7 08 12 2/48
>    ...above repeated 30 times...
>    # audio block/sample failure for 0 blocks, 60 samples of 1280
> 
> The resulting audio stream sounds odd, with little breaks in it. (As one 
> might expect if 60 out of every 1280 audio samples were bad.)
> 
> Details:
> --------
> Camera:     JVC GR-DVL28 (PAL)
> OS:         Mandrake 10, 2.6 kernel
> Libdv:      libdv 0.102  (libdv4-0.102-1mdk.rpm package)
> Other libs: libraw1394_5-0.9.0-4mdk, libdc1394_0-0.9.2-1mdk,
>             libavc1394_0-0.4.1-4mdk
[..]
> https://core.fluendo.com/trac/cgi-bin/trac.cgi/ticket/67
> which suggests there is a problem with JVC cameras and libdv.
> 
> So my questions: Has anyone else experienced this?  Is this a known 
> problem? Is there any workaround/fix?  Is there any more info I should 
> supply?

I have a JVC GR-DVL9600 (PAL), and audio has worked for me, except for some
occasional glitches, probably due to errors on the tape.  I've been using
libdv with the 2.4 kernel since 2.4.21 or so.

On a somewhat related note, there's a DV camera based backup utility whose name
escapes me right now.  My camera refused to record anything created by
that utility with the default settings.  If I remember correctly, there was
some option that generated silent audio instead of using the audio bandwidth
for the payload.  With that option, my camera recorded the data.  However,
playback didn't work reliably, even though I used the accompanying program
that adds redundance and spreads each byte across several blocks.

	Marko

[libdv-dev] Continuous "audio block/sample failure" with JVC DV camera

[Nathan K. <nat...@ya...>]

Hello,

Whenever I dump DV from my JVC camera I get continuous lines like:

    asf 00:00:00.00 2000-00-00 00:00:00 70 b7 08 12 2/48
    ...above repeated 30 times...
    # audio block/sample failure for 0 blocks, 60 samples of 1280

The resulting audio stream sounds odd, with little breaks in it. (As one 
might expect if 60 out of every 1280 audio samples were bad.)

Details:
--------
Camera:     JVC GR-DVL28 (PAL)
OS:         Mandrake 10, 2.6 kernel
Libdv:      libdv 0.102  (libdv4-0.102-1mdk.rpm package)
Other libs: libraw1394_5-0.9.0-4mdk, libdc1394_0-0.9.2-1mdk,
             libavc1394_0-0.4.1-4mdk

This problem occurs consistently and immediately with dvgrab 1.5/1.6 and 
Cinelerra 1.2.1.

Running the command
   dvgrab testvideo
immediately shows the "audio failure" output lines listed above.

I searched google and this list's archives, and the only reference to 
this I could find was
https://core.fluendo.com/trac/cgi-bin/trac.cgi/ticket/67
which suggests there is a problem with JVC cameras and libdv.

So my questions: Has anyone else experienced this?  Is this a known 
problem? Is there any workaround/fix?  Is there any more info I should 
supply?

I'd be grateful for any suggestions on how to debug this further.

Thanks to the developers (Buck and Dan especially) for making this lib!

Best Regards,

-Nathan

[libdv-dev] libdv 0.104 release

[Dan D. <da...@de...>]

Buck,
Please consider releasing libdv 0.104 now so we can get the x86-64 code
out for users. The version numbers have been bunmped already. Thanks!
+-DRD-+