libdv-dev

[libdv-dev] [ libdv-Bugs-1067765 ] Make problem using latest cygwin with latest X

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

Bugs item #1067765, was opened at 2004-11-16 17:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104393&aid=1067765&group_id=4393

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make problem using latest cygwin with latest X

Initial Comment:
./configure works but when I try to make, it complains
about the .type pseudo-op being outside of .def/.endef 

Tried adding .def a line above and .endef a line below
and it complains that it doesn't know how to resolve
the line.

Commenting out the lines also don't help because the
make bombs out later on when it can't find the function
declarations.

Can someone please help?

My compiler is gcc (GCC) 3.3.3 (cygwin special)

adr...@gm...

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

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

[libdv-dev] Re: [Fwd: [Kino-dev] x86_64 crash explored a bit]

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

I haven't really used kino. I need to know exactly how to reproduce the 
crash. I built kino 0.7.5 and clicked some buttons without causing a crash.

It's possible that the crash depends upon the video settings, such as NTSC 
vs PAL, etc. I might need a video file from you.

At 04:24 PM 11/10/2004, Dan Dennedy wrote:
>Dean, will you be able to look into this?
>
>-------- Forwarded Message --------
>From: Georg Ostertag <ge...@os...>
>To: kin...@li...
>Subject: [Kino-dev] x86_64 crash explored a bit
>Date: Wed, 10 Nov 2004 21:18:25 +0100
>Hi,
>
>I am back again with the crash of kino on x86_64 with
>the x86_64 optimized libdv.
>I attached a gdb to kino while crashing it.
>
>that's what I get:
>
>
>Single stepping until exit from function g_main_context_iterate,
>which has no line number information.
>0x0000002a97bcdbbd in g_main_loop_run () from /opt/gnome/lib64/libglib-
>2.0.so.0
>(gdb)
>Single stepping until exit from function g_main_loop_run,
>which has no line number information.
>
>Program received signal SIGSEGV, Segmentation fault.
>vlc_num_bits_block_x86_loop () at encode_x86_64.S:135
>135             movw    (%rdi), %ax
>Current language:  auto; currently asm
>(gdb)
>Detaching after fork from child process 6701.
>0x0000002a98be5f3d in fork () from /lib64/tls/libc.so.6
>(gdb) detach
>
>
>
>using ltrace to follow what's happening, I find as last words
>of kino:
>
>
>dv_parse_header(0x00e24a70, 0x2a9b02e010, 2, 0xffffffff, 413) = 1
>dv_parse_packs(0x00e24a70, 0x2a9b02e010, 0, 64, 0x2a9b02e1f0) =
>0xd8a6a8ff
>_ZNSs4_Rep10_M_destroyERKSaIcE(0x01010700, 0x7fbfffd160, 0x01010718, 0,
>2) = 0
>dv_decode_full_frame(0x00e24a70, 0x2a9b02e010, 1, 0x7fbfffd5b0,
>0x7fbfffd5a0) =
>0
>dv_encode_full_frame(0x01182da0, 0x7fbfffd608, 1, 0x2a9bb2b010,
>0x2a9b8e6c10 <un
>finished ...>
>--- SIGSEGV (Segmentation fault) ---
>
>So I am pretty shure, that there is some bug in the encoding
>part of libdv.
>Unfortunately, I have no idea how to fix it...
>
>Georg

[libdv-dev] [Fwd: [Kino-dev] x86_64 crash explored a bit]

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

Dean, will you be able to look into this?

-------- Forwarded Message --------
From: Georg Ostertag <ge...@os...>
To: kin...@li...
Subject: [Kino-dev] x86_64 crash explored a bit
Date: Wed, 10 Nov 2004 21:18:25 +0100
Hi,

I am back again with the crash of kino on x86_64 with
the x86_64 optimized libdv.
I attached a gdb to kino while crashing it.

that's what I get:


Single stepping until exit from function g_main_context_iterate,
which has no line number information.
0x0000002a97bcdbbd in g_main_loop_run () from /opt/gnome/lib64/libglib- 
2.0.so.0
(gdb)
Single stepping until exit from function g_main_loop_run,
which has no line number information.

Program received signal SIGSEGV, Segmentation fault.
vlc_num_bits_block_x86_loop () at encode_x86_64.S:135
135             movw    (%rdi), %ax
Current language:  auto; currently asm
(gdb)
Detaching after fork from child process 6701.
0x0000002a98be5f3d in fork () from /lib64/tls/libc.so.6
(gdb) detach



using ltrace to follow what's happening, I find as last words
of kino:


dv_parse_header(0x00e24a70, 0x2a9b02e010, 2, 0xffffffff, 413) = 1
dv_parse_packs(0x00e24a70, 0x2a9b02e010, 0, 64, 0x2a9b02e1f0) =  
0xd8a6a8ff
_ZNSs4_Rep10_M_destroyERKSaIcE(0x01010700, 0x7fbfffd160, 0x01010718, 0,  
2) = 0
dv_decode_full_frame(0x00e24a70, 0x2a9b02e010, 1, 0x7fbfffd5b0,  
0x7fbfffd5a0) =
0
dv_encode_full_frame(0x01182da0, 0x7fbfffd608, 1, 0x2a9bb2b010,  
0x2a9b8e6c10 <un
finished ...>
--- SIGSEGV (Segmentation fault) ---

So I am pretty shure, that there is some bug in the encoding
part of libdv.
Unfortunately, I have no idea how to fix it...

Georg

Re: [libdv-dev] odd results with playdv --dump-frames and Xv

[Chuck T. <ct...@gm...>]

On Thu, 4 Nov 2004 23:04:10 -0800, Roman Shaposhnick <rv...@su...> wrote:
> 
>   It seems overly complicated -- try ffmpeg instead:
> 
>     $ ./ffmpeg -i test.dv test%d.jpg

I didn't know about ffmpeg, and the above worked great. Thanks for your help!

---chuck

Re: [libdv-dev] odd results with playdv --dump-frames and Xv

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

On Thu, Nov 04, 2004 at 10:41:57PM -0800, Chuck Tuffli wrote:
> Hi. I'm running with the libdv-0.103 version of playdv on FreeBSD 4.9
> and trying to convert a single frame from DV to PPM with the
> --dump-frames option. playdv -l 0 displays the image correctly, but Xv
> displays the ppm file produced with the --dump-frames option as 3
> offset monochrome copies of the image. Should Xv be able to view the
> results (it at least claims to support ppm)? I was hoping to use Xv to
> convert the ppm to something like a JPEG image. Thanks for any
> insights.

  It seems overly complicated -- try ffmpeg instead:
  
    $ ./ffmpeg -i test.dv test%d.jpg

  will convert all your DV frames into jpg images. Or you could choose
  any other format of your choice (gif, png, etc) just change the 
  extension.

Thanks,
Roman.

[libdv-dev] odd results with playdv --dump-frames and Xv

[Chuck T. <ct...@gm...>]

Hi. I'm running with the libdv-0.103 version of playdv on FreeBSD 4.9
and trying to convert a single frame from DV to PPM with the
--dump-frames option. playdv -l 0 displays the image correctly, but Xv
displays the ppm file produced with the --dump-frames option as 3
offset monochrome copies of the image. Should Xv be able to view the
results (it at least claims to support ppm)? I was hoping to use Xv to
convert the ppm to something like a JPEG image. Thanks for any
insights.

---chuck

[libdv-dev] Controlling a cassette recorder through DV in/out

[Babar N. <bab...@gm...>]

Hi,

I know this is not a windows forum, but I need to know if this thing
is implementable on other platforms.
I am working with two Sony GV-D200E Video cassette recorders. I have a
1394 card on my PC. I connected the two sony players to my computer
through the DV in/out pin. I wrote a program to playback the two sony
players simultaneously and display the output on the screen in two
different windows, using Microsoft DirectShow and Visual C++. Now I
need to synchronize both the players. One way which is simple is to
synchronize both of them using the SMPTE time format. But I dont need
to synchronize them on SMPTE. The cassettes that I am playing have a
"Relative Time Counter" (RTC) in them, I want to synchronize them on
the RTC time, but using Microsoft DirectShow I am unable to retrieve
the RTC time through these devices.

My question is Have anyone in this project ever tried to retrieve the
RTC through the DV?
Is there any limitation on the sony devices? (I asked sony about this,
still waiting for their reply).

I posted this question on one of the windows list and they directed me here.

Regards

Babar Noor

[libdv-dev] Re: [Kino-dev] Re: Kino-dev digest, Vol 1 #728 - 2 msgs

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

Georg Ostertag wrote:
> Today I compiled libdv-cvs-2004-10-26 on three 64bit platforms
> and ran playdv with pond.dv:
>
> Dual AMD Opteron 2.2GHz
> compiles, playdv uses about 16% CPU, framerate fine.
>
> Dual Intel Xeon 3.2GHz with EM64T extension (x86_64 instruction set):
> compiles, playdv uses about 13% CPU, framerate fine.
>
> Dual Itanium 2 1.6 GHz
> compiles, playdv uses 50% CPU (on complete CPU), framerate bad.

Great! Thank you for doing this.

> The Itanium is worse, as there is no asm optimization for it...?

Correct, this was an x86-64 port, not IA64, which the Itanium uses.

Hmm.. can anyone reproduce the crash on encoding with Kino as recently
reported? Otherwise, we can make a new libdv release.

Re: [libdv-dev] 24fps and true 16:9 DV samples

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

Hi Dan,

Steve has answered most of the questions and I'll just reiterate
a little bit:

On Tue, Nov 02, 2004 at 09:22:32AM -0500, da...@de... wrote:
> > I'm trying to figure out how to handle 24fps shooting mode and
> > "true" 16:9 in DV. So, if there's somebody out there with equipment
> > that is capable of producing such footage -- I'd be very grateful  if
> > you can share at least 1sec worth of it with me.
> 
> I have some samples of different 16:9 modes that were shared here
> previously. I can make them available tonight. What do you mean by true
> 16:9? As far as I know, there is only anamorphic (aka squeeze) and
> letterboxed.

  That's what I'm trying to find out. See Steve's reply about 
  the "wider" CCD. I guess I just need to find a high-end video
  store and ask them to tape a couple of secs. on their XL2.

> Also, for some reason - perhaps based on past casual reading at
> digitalmedianet.com - I believe that the 24fps DV is progressive scan with
> a 2:3 pulldown applied to make it run at normal rates for compatibility
> with existing DV tech. Hopefully, there is some flag in the stream. What
> information do you already have about this?

  Very little. I'd like to look for suspicious flags that could hint
  about 24fps and see what ffmpeg DV can do about it. But that'll be
  pretty much reverse engineering -- that's why I need some samples.

Thanks,
Roman.

Re: [libdv-dev] 24fps and true 16:9 DV samples

[Steven M. S. <sm...@2B...>]

On Tue, 2 Nov 2004 da...@de... wrote:

> I have some samples of different 16:9 modes that were shared here
> previously. I can make them available tonight. What do you mean by true
> 16:9? As far as I know, there is only anamorphic (aka squeeze) and
> letterboxed.

	Camcorders usually have a 4:3 CCD and either use a letterboxed
	area of the CCD (basically the middle 360 pixels out of 480) _or_
	an anamorphic lens adaptor.

	I have read about new camcorders that have a 16:9 CCD and use a
	~960 area of the CCD and do not  letterbox or require an anamorphic
	lens.   960 10:11 pixels works out to around 854 square pixels - the
	rest of the arithmetic is left as an exercise for the reader :)

	Couple good examples of non-letterboxed 16:9 CCD camcorders are
	the Canon XL2 and the Panasonic AG-DVC200.

	What's puzzling is what happens next.  If a 16:9 CCD is used without
	an anamorphic lens then is the ~960x480 frame put on tape or does
	the camcorder scale/resample to anamorphic form?

> Also, for some reason - perhaps based on past casual reading at
> digitalmedianet.com - I believe that the 24fps DV is progressive scan with
> a 2:3 pulldown applied to make it run at normal rates for compatibility

	Yes, that's what I have read also.

	Panasonic (and perhaps others) also offer a "24P Advanced" mode
	which uses a 2:3:3:2 pulldown rather than a strict 2:3 pattern.

http://catalog2.panasonic.com/webapp/wcs/stores/servlet/ModelDetail?storeId=11201&catalogId=13051&itemId=68668&catGroupId=14571&displayTab=R&surfModel=AG-DVX100A&surfCategory=DV%20PROLINE%20Camcorders

	sorry it's so long but it might be of interest.

> with existing DV tech. Hopefully, there is some flag in the stream. What
> information do you already have about this?

	The only info I have is from the various vendor's sites (Canon, 
	Panasonic, and so on) and Apple's Final Cut Pro-HD (which claims to
	deal with everything up to HD) documentation.


	Cheers,
	Steven Schultz

Re: [libdv-dev] 24fps and true 16:9 DV samples

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

> I'm trying to figure out how to handle 24fps shooting mode and
> "true" 16:9 in DV. So, if there's somebody out there with equipment
> that is capable of producing such footage -- I'd be very grateful  if
> you can share at least 1sec worth of it with me.

I have some samples of different 16:9 modes that were shared here
previously. I can make them available tonight. What do you mean by true
16:9? As far as I know, there is only anamorphic (aka squeeze) and
letterboxed.
Also, for some reason - perhaps based on past casual reading at
digitalmedianet.com - I believe that the 24fps DV is progressive scan with
a 2:3 pulldown applied to make it run at normal rates for compatibility
with existing DV tech. Hopefully, there is some flag in the stream. What
information do you already have about this?

[libdv-dev] 24fps and true 16:9 DV samples

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

I'm trying to figure out how to handle 24fps shooting mode and 
"true" 16:9 in DV. So, if there's somebody out there with equipment 
that is capable of producing such footage -- I'd be very grateful 
if you can share at least 1sec worth of it with me.

Cannon XL2 is a perfect choice for this task.

Thanks,
Roman.

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

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

>  I kinda lost you here. Why --disable-asm is important ? It's known to
>  be way slower anyway.

heh, because the latest libdv _release_ will not run with mmx/asm forcibly
enabled on x86-64. The point of Dean's effort was to just to get the
asm/mmx working again.
>> current libdv release. I told him that asm/mmx was disabled due to
>> arch detection at configure. I asked him to try CVS, he did, and
>> reported a huge performance gain, of course.
>
>  Hm. I went and checked and I saw the following .o's under .lib/:
>
>    dct_block_mmx_x86_64.o
[...]
>  so it would seem that x86_64 support gets used.

Yes, on CVS now that does happen, but I was referring to the current
_release_. 64bit users will be at least somewhat content because they will
not have to suffer with no accelleration!
>  Interesting. Of course ffmpeg's stable release is long overdue, but
>  CVS should be quite stable as far as DV is concerned. Are you sure


>  that it failed in DV decoding, not when user tried to export stuff
>  into mpeg4 or something.

avcodec_decode_video (or similar) is at the top of the callstack just
before the calls into the segv handler. Of course, I can't reproduce it.
Also, unfortunately, there are no args on the backtrace. If you can test
and not reproduce it, then I will close the bug as not reproducible and to
try with the latest ffmpeg CVS.

Re: [libdv-dev] decoding failures on *second* try

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

> Hi,
>
> we're using libdv (by way of gstreamer) to grab data from a JVC GY-DV
> 300 camera.  I'm seeing a strange problem that I almost can't believe,
> but it appears to be like this:
>
> On the first attempt to grab data, everything works.  On subsequent
> attempts, I get "audio decoding failure" (and every once on a while
> "audio packet decoding failure") *continously*.  No audio can be
> recovered at all.
>
> Unplugging the firewire doesn't help, but when attaching a different
> make of camera (a Sony) and then re-attaching the JVC, it again works
> -- once!
>
> Do you guys have an idea on what could be going wrong here?  I'm at my
> wits end!

I do not recall ever experiencing this problem or hearing about it from
others. However, please explain more clearly your process for "first
attempt to grab data... subsequent attempts...." Are you gst-record or
similar for grabbing? Have you confirmed this problem using other tools
like dvgrab or ffmpeg?

[libdv-dev] decoding failures on *second* try

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

Hi,

we're using libdv (by way of gstreamer) to grab data from a JVC GY-DV
300 camera.  I'm seeing a strange problem that I almost can't believe,
but it appears to be like this:

On the first attempt to grab data, everything works.  On subsequent
attempts, I get "audio decoding failure" (and every once on a while
"audio packet decoding failure") *continously*.  No audio can be
recovered at all.

Unplugging the firewire doesn't help, but when attaching a different
make of camera (a Sony) and then re-attaching the JVC, it again works
-- once!

Do you guys have an idea on what could be going wrong here?  I'm at my wits end!

regards,

Ingo

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

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

Before I fixed it up for x86-64, it was always being built entirely from C, 
no assembly language, and so slow it wasn't usable when built on x86-64.

Keep in mind there's a difference between building on x86-64 and running 
x86 code on an AMD64 machine. Apparently most people are running x86 
software on AMD64 machines. dvgrab seg faults on Fedora x86-64. mjpegtools 
seems to have x86 but not x86-64 assembly.

--disable-asm forces the new version to be built as all C, even if it could 
be build with assembly code, for comparison. It was intended to be usable, 
not faster than anything else.

I just made a line-for line fixup of the x86 assembly to get it to assemble 
on x86-64. Someone who really knows AMD64 should be able to speed it up 
quite a bit. There's also a lot of matrix arithmetic shortcuts to 
understand, but not documented.


At 07:00 PM 10/27/2004, Roman Shaposhnick wrote:
>On Wed, Oct 27, 2004 at 09:47:58PM -0400, Dan Dennedy wrote:
> > On Wed, 2004-10-27 at 00:13 -0700, Roman Shaposhnick wrote:
> > > On Wed, Oct 13, 2004 at 07:03:35AM -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.
> > >
> > >   Well CVS obviously works on Opteron/SuSE 8. So that's covered. Now
> > >   for the bad news. For some reason it takes almost twice the time to
> > >   decode pond.dv (8.7 user) compared to the ffmpeg with x86_64
> > >   enabled DV decoder (4.7 user).
> >
> > Dean did say it was not optimised for 64bit, just a minimal port. I
> > expect ffmpeg to be better - both 32 and 64bit. The real comparison to
> > be made is against --disable-asm.
>
>   I kinda lost you here. Why --disable-asm is important ? It's known
>   to be way slower anyway.
>
> > A user sent an e-mail after my
> > announcement on kino forum, and said his system worked fine with the
> > current libdv release. I told him that asm/mmx was disabled due to arch
> > detection at configure. I asked him to try CVS, he did, and reported a
> > huge performance gain, of course.
>
>   Hm. I went and checked and I saw the following .o's under .lib/:
>
>     dct_block_mmx_x86_64.o
>     encode_x86_64.o
>     idct_block_mmx_x86_64.o
>     quant_x86_64.o
>     rgbtoyuv_x86_64.o
>     transpose_x86_64.o
>
>   so it would seem that x86_64 support gets used.
>
> > Also, Kino's bugtracker http://jira.schirmacher.de/ contains a segfault
> > with backtrace bug report of an amd64 user using kino compiled against
> > libavcodec. It should be easy to spot in the list. However, it contains
> > no libavcodec version indication. As a matter of fact, that sort of
> > thing is rather hard for users to track and report as many ffmpeg users
> > are not using an official ffmpeg release.
>
>   Interesting. Of course ffmpeg's stable release is long overdue, but
>   CVS should be quite stable as far as DV is concerned. Are you sure
>   that it failed in DV decoding, not when user tried to export stuff
>   into mpeg4 or something.
>
>   Anyway, tomorrow I'll give it a try on my Opteron box.
>
>Thanks,
>Roman.
>
>P.S. Of course I'm biased, but it seems that Sun manufactures a real killer
>Opteron boxes...

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

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

On Wed, Oct 27, 2004 at 09:47:58PM -0400, Dan Dennedy wrote:
> On Wed, 2004-10-27 at 00:13 -0700, Roman Shaposhnick wrote:
> > On Wed, Oct 13, 2004 at 07:03:35AM -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.
> > 
> >   Well CVS obviously works on Opteron/SuSE 8. So that's covered. Now 
> >   for the bad news. For some reason it takes almost twice the time to
> >   decode pond.dv (8.7 user) compared to the ffmpeg with x86_64
> >   enabled DV decoder (4.7 user).
> 
> Dean did say it was not optimised for 64bit, just a minimal port. I
> expect ffmpeg to be better - both 32 and 64bit. The real comparison to
> be made is against --disable-asm. 

  I kinda lost you here. Why --disable-asm is important ? It's known
  to be way slower anyway.

> A user sent an e-mail after my
> announcement on kino forum, and said his system worked fine with the
> current libdv release. I told him that asm/mmx was disabled due to arch
> detection at configure. I asked him to try CVS, he did, and reported a
> huge performance gain, of course.

  Hm. I went and checked and I saw the following .o's under .lib/:

    dct_block_mmx_x86_64.o
    encode_x86_64.o
    idct_block_mmx_x86_64.o
    quant_x86_64.o
    rgbtoyuv_x86_64.o
    transpose_x86_64.o

  so it would seem that x86_64 support gets used.

> Also, Kino's bugtracker http://jira.schirmacher.de/ contains a segfault
> with backtrace bug report of an amd64 user using kino compiled against
> libavcodec. It should be easy to spot in the list. However, it contains
> no libavcodec version indication. As a matter of fact, that sort of
> thing is rather hard for users to track and report as many ffmpeg users
> are not using an official ffmpeg release.

  Interesting. Of course ffmpeg's stable release is long overdue, but
  CVS should be quite stable as far as DV is concerned. Are you sure
  that it failed in DV decoding, not when user tried to export stuff
  into mpeg4 or something.

  Anyway, tomorrow I'll give it a try on my Opteron box.

Thanks,
Roman.

P.S. Of course I'm biased, but it seems that Sun manufactures a real killer
Opteron boxes...

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

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

On Wed, 2004-10-27 at 00:13 -0700, Roman Shaposhnick wrote:
> On Wed, Oct 13, 2004 at 07:03:35AM -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.
> 
>   Well CVS obviously works on Opteron/SuSE 8. So that's covered. Now 
>   for the bad news. For some reason it takes almost twice the time to
>   decode pond.dv (8.7 user) compared to the ffmpeg with x86_64
>   enabled DV decoder (4.7 user).

Dean did say it was not optimised for 64bit, just a minimal port. I
expect ffmpeg to be better - both 32 and 64bit. The real comparison to
be made is against --disable-asm. A user sent an e-mail after my
announcement on kino forum, and said his system worked fine with the
current libdv release. I told him that asm/mmx was disabled due to arch
detection at configure. I asked him to try CVS, he did, and reported a
huge performance gain, of course.

Also, Kino's bugtracker http://jira.schirmacher.de/ contains a segfault
with backtrace bug report of an amd64 user using kino compiled against
libavcodec. It should be easy to spot in the list. However, it contains
no libavcodec version indication. As a matter of fact, that sort of
thing is rather hard for users to track and report as many ffmpeg users
are not using an official ffmpeg release.

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

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

On Wed, Oct 13, 2004 at 07:03:35AM -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.

  Well CVS obviously works on Opteron/SuSE 8. So that's covered. Now 
  for the bad news. For some reason it takes almost twice the time to
  decode pond.dv (8.7 user) compared to the ffmpeg with x86_64
  enabled DV decoder (4.7 user).

  I will continue with my testing tomorrow. And will try encoding.

Thanks,
Roman.
 
> 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] automake error/warning - fatal?

[Steven M. S. <sm...@2B...>]

On Thu, 21 Oct 2004, Dan Dennedy wrote:

> > 	(this is on OS/X 10.3.5 using automake 1.7.9):
> 
> using v1.9.2 here with no error

	automake 1.8.3 or so didn't give any error - so perhaps it's time
	to (sigh) upgrade the version of automake I use on OS/X

> > 	2) is it a "Bad Thing" or can it safely be ignored?
> 
> I dunno. If simply does not build gasmoff, then it is not critical and
> can be ignored. Can you verify playdv still works?

	Well, 'playdv' has never worked on OS/X so I can truthfully say
	that it runs as well now as it ever has :)

	Without "--enable-sdl" I get the (expected) "playdv was compiled
	without SDL support".  But there seems to be something awry with
	the --enable-sdl (or the version of SDL that was used in playdv - I
	have 1.2.8 installed) because trying to enable SDL yields:

display.c: In function `dv_center_window':
display.c:609: error: structure has no member named `subsystem'
display.c:609: error: `SDL_SYSWM_X11' undeclared (first use in this function)
display.c:609: error: (Each undeclared identifier is reported only once
display.c:609: error: for each function it appears in.)
display.c:610: error: structure has no member named `info'
display.c:612: error: structure has no member named `info'
display.c:612: error: structure has no member named `info'
display.c:614: error: structure has no member named `info'
display.c:614: error: structure has no member named `info'
display.c:617: error: structure has no member named `info'
display.c:617: error: structure has no member named `info'
display.c:618: error: structure has no member named `info'

	It's not important though that 'playdv' run - all I really need/want
	is 'libdv' itself.  MPlayer and other programs can handle the playback
	of the DV files.

	Cheers,
	Steven Schultz

Re: [libdv-dev] automake error/warning - fatal?

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

On Wed, 2004-10-20 at 20:23 -0700, Steven M. Schultz wrote:
> Hi -
> 
> 	After a cvs update a few minutes ago I'm seeing an automake error
> 	(this is on OS/X 10.3.5 using automake 1.7.9):

using v1.9.2 here with no error

> [LARRY:src/libdv-cvs] sms% ./bootstrap 
> + aclocal
> + libtoolize --force --copy
> + aclocal
> + autoheader
> + automake --foreign --copy --add-missing
> configure.ac: installing `./missing'
> libdv/Makefile.am:19: automake does not support conditional definition of GASMOFF in noinst_PROGRAMS
> + autoconf
> 
> 	Is this 1) related to the (major) changes that were made recently and

yes

> 	2) is it a "Bad Thing" or can it safely be ignored?

I dunno. If simply does not build gasmoff, then it is not critical and
can be ignored. Can you verify playdv still works?

[libdv-dev] automake error/warning - fatal?

[Steven M. S. <sm...@2B...>]

Hi -

	After a cvs update a few minutes ago I'm seeing an automake error
	(this is on OS/X 10.3.5 using automake 1.7.9):

[LARRY:src/libdv-cvs] sms% ./bootstrap 
+ aclocal
+ libtoolize --force --copy
+ aclocal
+ autoheader
+ automake --foreign --copy --add-missing
configure.ac: installing `./missing'
libdv/Makefile.am:19: automake does not support conditional definition of GASMOFF in noinst_PROGRAMS
+ autoconf

	Is this 1) related to the (major) changes that were made recently and
	2) is it a "Bad Thing" or can it safely be ignored?

	Cheers,
	Steven Schultz

[libdv-dev] Re: libdv for AMD64

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

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 am very happy to announce that this has been committed to CVS with
only a minor build fix. Thank you for the hard work you put into this.

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

OK, not looked at yet.

> 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 have not yet looked into this either.

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

I hope now that it is in CVS we can get some testing. I will post a
message to the Kino website to solicit testers.

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

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

On Wed, Oct 13, 2004 at 07:03:35AM -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.

 ffmpeg has got and AMD64 boost recently as well, so it'll be interesting to
 compare results w.r.t. speed of decoding/encoding.

Thanks,
Roman.
 
> 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

[libdv-dev] Re: libdv for AMD64

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

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
>