libdv-dev

[libdv-dev] 1920 and 1921 samples

[Leander S. <leg...@t-...>]

Hello,

when decoding dv video libdv gives me sometimes
1921 audio samples instead of the expected 1920.
I' assume that this is some additional sample
to match the 25fps (PAL) timecode, but dividing
48000/25 gives exactly 1920 so this seems not to be
necessary. And: when I simply ignore this additional
sample the sound stops crackling in my program. 
But maybe the timing in my program isn't that
perfect yet.

Regards,
Leander Seige

[libdv-dev] [ libdv-Bugs-1584980 ] --with-pal-yuv=YV12

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

Bugs item #1584980, was opened at 2006-10-26 03:06
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=1584980&group_id=4393

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: --with-pal-yuv=YV12

Initial Comment:
I have been using libdv to decode dv pal dv frams with
a resolution of 720 x 576. I built libdv with the above
option. However when using dv_decode_full_frame in the
yuv colour space, the pitches pointer seems to get a
little trashed. In the function 
void 
dv_mb420_YV12_mmx(dv_macroblock_t *mb, uint8_t
**pixels, uint16_t *pitches,
                  int clamp_luma, int clamp_chroma) in
YV12.c, the value for the pitches[1] is also zero when
set from elsewhere. I am assuming that this is being
trashed somewhere.
Jonathan Owen

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

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

[libdv-dev] LIBDV - Problem with clip length

[Ruslan P. <rp...@je...>]

Can you help me?
All info in attachment!
-- 

            _/               Ruslan Popov
           _/   _/_/   _/
          _/  _/  _/  _/     The expert  of Dozor-Jet's
         _/ _/_/_/_/ _/_/        implementation team
        _/ _/       _/       Mobile: +7 (916) 926-12-05
    _/_/   _/_/_/  _/        Office: +7 (495) 411-76-01
     Infosystems   _/_/      Moscow, Russia

Re: [libdv-dev] Text relocations in x86 assembly code

[Mike F. <va...@ge...>]

On Tuesday 26 September 2006 09:42, Jarod Wilson wrote:
> The one referenced in a thread or three a couple of months back:

yeah, dont use that :)

> I'll poke at it some myself. I've got a test case that caused segfaults
> reliably with the earlier version Fedora had.

thanks

> Heh, I like the explicit call-out of libdv as a problem in the hardened
> gentoo pic-fix-guide... :)

eh, it was a scanelf of whatever i happened to have installed at the time

i keep meaning to put together "focused" guides where i go into detail of h=
ow=20
a specific package was fixed ...
=2Dmike

Re: [libdv-dev] Text relocations in x86 assembly code

[Jarod W. <jw...@re...>]

On Tue, 2006-09-26 at 01:28 -0400, Mike Frysinger wrote:
> On Monday 25 September 2006 18:01, Jarod Wilson wrote:
> > I presume this is a repaired version of the one that was causing
> > segfaults on i386?
>=20
> *shrug* dont really know which one you're referring to ...

The one referenced in a thread or three a couple of months back:

http://sourceforge.net/mailarchive/message.php?msg_id=3D15422283
http://sourceforge.net/mailarchive/forum.php?thread_id=3D14663616&forum_id=
=3D5458

Someone swiped it from Gentoo's libdv and put it in the Fedora libdv at
some point before I took over the package.

> you can find the latest here:
> http://bugs.gentoo.org/121871
>=20
> may be suitable for distros but i'd like to improve it a bit more before=20
> submitting to libdv

I'll poke at it some myself. I've got a test case that caused segfaults
reliably with the earlier version Fedora had.

Heh, I like the explicit call-out of libdv as a problem in the hardened
gentoo pic-fix-guide... :)


--=20
Jarod Wilson
jw...@re...

Re: [libdv-dev] Text relocations in x86 assembly code

[Mike F. <va...@ge...>]

On Monday 25 September 2006 18:01, Jarod Wilson wrote:
> I presume this is a repaired version of the one that was causing
> segfaults on i386?

*shrug* dont really know which one you're referring to ...

you can find the latest here:
http://bugs.gentoo.org/121871

may be suitable for distros but i'd like to improve it a bit more before=20
submitting to libdv
=2Dmike

Re: [libdv-dev] Text relocations in x86 assembly code

[Jarod W. <jw...@re...>]

On Mon, 2006-09-25 at 17:47 -0400, Mike Frysinger wrote:
> On Friday 22 September 2006 16:33, Mike Frysinger wrote:
> > On Friday 22 September 2006 16:21, Jarod Wilson wrote:
> > > The long and short of it is that there are text relocations in the x8=
6
> > > assembly code, which means libdv won't function with selinux enabled.=
 I
> > > know very little assembly (touched it years ago in a college course),=
 so
> > > I'm hoping someone else might have an idea how to remedy the problem,
> > > short of using --disable-asm to build.
> >
> > we've been working on this in Gentoo, but some of the initial cleanup
> > patches ive posted to the list have yet to be merged so i havent pushed=
 the
> > more fun ones yet ...
>=20
> looks like i was mistaken ... last time i looked the patches werent merge=
d,=20
> but they're def in there now :)

Ah, okay, I've got those in hand already then... :)

> i'll see about updating our PIC patch from 0.104 to 1.0.0/cvs then and po=
st it=20
> here

I presume this is a repaired version of the one that was causing
segfaults on i386?

--=20
Jarod Wilson
jw...@re...

Re: [libdv-dev] Text relocations in x86 assembly code

[Mike F. <va...@ge...>]

On Friday 22 September 2006 16:33, Mike Frysinger wrote:
> On Friday 22 September 2006 16:21, Jarod Wilson wrote:
> > The long and short of it is that there are text relocations in the x86
> > assembly code, which means libdv won't function with selinux enabled. I
> > know very little assembly (touched it years ago in a college course), so
> > I'm hoping someone else might have an idea how to remedy the problem,
> > short of using --disable-asm to build.
>
> we've been working on this in Gentoo, but some of the initial cleanup
> patches ive posted to the list have yet to be merged so i havent pushed t=
he
> more fun ones yet ...

looks like i was mistaken ... last time i looked the patches werent merged,=
=20
but they're def in there now :)

i'll see about updating our PIC patch from 0.104 to 1.0.0/cvs then and post=
 it=20
here
=2Dmike

Re: [libdv-dev] Text relocations in x86 assembly code

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

On Fri, Sep 22, 2006 at 04:21:57PM -0400, Jarod Wilson wrote:
> The long and short of it is that there are text relocations in the x86
> assembly code, which means libdv won't function with selinux enabled. I
> know very little assembly (touched it years ago in a college course), so
> I'm hoping someone else might have an idea how to remedy the problem,
> short of using --disable-asm to build.

See also http://bugs.debian.org/175077. We're treating this problem at
low severity as fixes are likely to impact performance.

Regards,

Daniel.

Re: [libdv-dev] Text relocations in x86 assembly code

[Mike F. <va...@ge...>]

On Friday 22 September 2006 16:21, Jarod Wilson wrote:
> The long and short of it is that there are text relocations in the x86
> assembly code, which means libdv won't function with selinux enabled. I
> know very little assembly (touched it years ago in a college course), so
> I'm hoping someone else might have an idea how to remedy the problem,
> short of using --disable-asm to build.

we've been working on this in Gentoo, but some of the initial cleanup patch=
es=20
ive posted to the list have yet to be merged so i havent pushed the more fu=
n=20
ones yet ...
=2Dmike

[libdv-dev] Text relocations in x86 assembly code

[Jarod W. <jw...@re...>]

Hi there,

I got handed libdv maintainership for Fedora a while back, and have had
a bug against Fedora's libdv on the back-burner for a while that I'm
finally getting around to looking at...

The long and short of it is that there are text relocations in the x86
assembly code, which means libdv won't function with selinux enabled. I
know very little assembly (touched it years ago in a college course), so
I'm hoping someone else might have an idea how to remedy the problem,
short of using --disable-asm to build.

References:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D146596
http://people.redhat.com/drepper/textrelocs.html

Thanks much!

--=20
Jarod Wilson
jw...@re...

[libdv-dev] [ libdv-Patches-1562254 ] libdv-0.104: undefined C code and uninitialized variable

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

Patches item #1562254, was opened at 2006-09-20 14:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304393&aid=1562254&group_id=4393

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: anosek (anosek)
Assigned to: Nobody/Anonymous (nobody)
Summary: libdv-0.104: undefined C code and uninitialized variable

Initial Comment:
Wrote by David Binderman:
I just tried to compile package libdv-0.104-4 with a
prerelease of the
GNU C compiler version 4.1. It said

1.

encode.c:1811: warning: operation on "i" may be undefined

The source code is

                for (i = 0;
                        i < (DV_WIDTH * (dv_enc->isPAL
? DV_PAL_HEIGHT :
DV_NTSC_HEIGHT));
                        dv_enc->img_y[i] =
CLAMP(dv_enc->img_y[i++], -224, 214)
);

I agree with the compiler - this code seems to be
undefined.

There is also use of uninitialized variable "w".

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

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

[libdv-dev] deconding benchmark on ARM

[Oliver Z. <oz...@co...>]

Hi there!
I'm trying to do a benchmark for decoding DV data on an ARM machine
(arm920t core, 180MHz, 64MB SDRAM).

Here's the code:
--------------------------------------------------------
// decode.c
#include <stdio.h>
#include <sys/time.h>
#include <fcntl.h>
#include <libdv/dv.h>

#define READ_SIZE 120000 // PAL 144000
int main(int argc,char *argv[])
{
   dv_decoder_t *decoder = NULL;
   int fd, dec, count;
   unsigned char *pixels[3];
   int pitches[3];
   unsigned char video_buffer[720 * 576 * 3];
   unsigned char dv_buffer[READ_SIZE];
   struct timeval tv[3];
   double time = 0.0;
  
   if ((fd = open(argv[1],O_RDONLY)) < 0)
      printf("could not open file %s\n\n",argv[1]);
   else
      printf("opened file %s\n\n", argv[1]);
   pitches[0] = 720 * 3;
   pixels[0] = video_buffer;
   decoder = dv_decoder_new(TRUE, FALSE, FALSE);
   dec = count = 1;

   if (!decoder)
      printf("decoder new failed\n");

   if (READ_SIZE != read(fd, dv_buffer, READ_SIZE))
      printf("read failed\n");

   if (dv_parse_header(decoder, dv_buffer) < 0)
      printf("header parse error\n");

   printf("decoding...\n\n");
   gettimeofday(tv+0, NULL);
   dv_decode_full_frame(decoder, dv_buffer, e_dv_color_rgb, pixels,
pitches);

   while (dec) {
      if (READ_SIZE == read(fd, dv_buffer, READ_SIZE))
      {
         dv_decode_full_frame(decoder, dv_buffer, e_dv_color_rgb,
pixels, pitches);
         count++;
         //printf("frame no.: %d\n\n", count);
      } else dec = 0;
   } // while
   gettimeofday(tv+1, NULL);
   timersub(tv+1, tv+0, tv+2);
   time = tv[2].tv_sec + (tv[2].tv_usec / 1000000.0);
   printf("seconds: %f\n", time);
   printf("number of frames: %d\n", count);
   printf("resulting in %f fps\n", (double)count / time);
   close(fd);
   dv_decoder_free(decoder);
   return 0;
} // main
--------------------------------------------------

I configured libdv for arm:
./configure --disable-gtk --host=arm-linux --target=arm-linux

Cross-compiled with arm-linux-gcc (2.95.3) on my x86:
arm-linux-gcc -o arm-decode -ldv -O -O2 decode.c

Works so far but the performance is terrible. Decoding just one frame
takes several minutes (file pond.dv).
So my question is: is there any possiblity to improve speed?
Thank you!

Oliver

[libdv-dev] [ libdv-Patches-1550898 ] export messes up when samples_this_frame == 0

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

Patches item #1550898, was opened at 2006-09-01 23:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304393&aid=1550898&group_id=4393

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Craig Lawson (claw11)
Assigned to: Nobody/Anonymous (nobody)
Summary: export messes up when samples_this_frame == 0

Initial Comment:
This patch for libdv-0.104. It addresses a minor
problem with exporting to a RAW DV file where audio
noise is introduced. The problem arises when
samples_this_frame == 0 and dv_encode_full_audio()
calculates audio.bytesperframe. When bytesperframe is
calculated, its units are bytes (correct), but
_dv_raw_insert_audio() then assumes the units are
samples (wrong).

  In contrast, when samples_this_frame != 0,
audio.bytesperframe is set to samples_this_frame and
_dv_raw_insert_audio() is then correct to treat the
value as samples. So depending on samples_this_frame,
the units of audio.bytesperframe is either bytes or
samples.

  This patch corrects the use of audio.bytesperframe so
units are always bytes.


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

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

[libdv-dev] playdv frees memeory twice and crashes

[Don H. <don...@co...>]

I have tried this with both CVS and the current beta version.  The same
thing happens.
I can play a dv file, at the end of the file it crashes.
format 16:9
Audio is 32.0 kHz, 12 bits quantization, 2 channels, emphasis off
Xv: NV17 Video Texture: ports 274 - 274
Xv: grabbed port 274
 Using Xv for display
Processed 189 frames in 17.30 seconds (10.92 fps)
*** glibc detected *** playdv: double free or corruption (fasttop):
0x0805c6e8 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7b9d911]
/lib/libc.so.6(__libc_free+0x84)[0xb7b9ef84]
playdv(dv_display_exit+0x57)[0x804bf7b]
playdv(main+0x8b2)[0x804adfa]
I compiled the beta version with debug and found out where it occurs. 
It seems that display.c line 246 is executed twice and tries to free
memory that has already been freed.
Here is a summary of a trace:
display.c :246 267 268 267
playdv.c:514 515
oss.c:194 195 196 197 199 200 201 203 201
playdv.c:517
dv.c:159 160-165
playdv.c:518 519
display.c:686 234 235 238 241-246 and then it frees the same memory
again which causes a crash
I am using suse 10.1. Perhaps it has some enhancements which will catch
this that other distributions don't.

Re: [libdv-dev] [patch] add some sanity checks to bootstrap script

[Mike F. <va...@ge...>]

On Sunday 06 August 2006 17:03, Dan Dennedy wrote:
> On Sunday 06 August 2006 13:02, Mike Frysinger wrote:
> > On Sunday 06 August 2006 15:56, Dan Dennedy wrote:
> > > I dont care about maintaining bootstrap; use autoreconf.
> >
> > ... then punt it from cvs ?
>
> I just changed bootstrap to invoke autoreconf and accidentally I updated
> all of the generated files, which I prefer not to have in CVS, but the
> release manager does.

that works, thanks
-mike

Re: [libdv-dev] [patch] add some sanity checks to bootstrap script

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

On Sunday 06 August 2006 13:02, Mike Frysinger wrote:
> On Sunday 06 August 2006 15:56, Dan Dennedy wrote:
> > I dont care about maintaining bootstrap; use autoreconf.
>
> ... then punt it from cvs ?

I just changed bootstrap to invoke autoreconf and accidentally I updated all 
of the generated files, which I prefer not to have in CVS, but the release 
manager does. 

Re: [libdv-dev] [PATCH] Less trouble without gtk-1.x

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

On Tuesday 09 May 2006 03:04, pl...@ip... wrote:
> the attached patch let's configure succeed if gtk-1.x is not found
> (before, one had to explicitely use the --disable-gtk flag).
> Furthermore it enables calling "make dist" for people, who don't have
> gtk-1.x.

applied. sorry to take so long to respond. trying to care for so many projects 
with insufficient effort, but today libdv gets attention. I think it's time 
for a new release with so many community patches applied :-)

Re: [libdv-dev] [patch] add some sanity checks to bootstrap script

[Mike F. <va...@ge...>]

On Sunday 06 August 2006 15:56, Dan Dennedy wrote:
> I dont care about maintaining bootstrap; use autoreconf.

... then punt it from cvs ?
-mike

Re: [libdv-dev] [patch] add some sanity checks to bootstrap script

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

I dont care about maintaining bootstrap; use autoreconf.

On Sunday 25 June 2006 09:11, Mike Frysinger wrote:
> On Sunday 25 June 2006 07:31, Daniel Kobras wrote:
> > On Sun, Jun 25, 2006 at 03:45:25AM -0400, Mike Frysinger wrote:
> > > simple patch ... if some autotool fails, abort the script, dont just
> > > keep running
> >
> > How about this even simpler version to achieve the same?
>
> yes, some people use set -e to accomplish the same thing, it's just been my
> experience that truly portable projects go with '|| exit' instead of 'set
> -e'
>
> either works for me though, i'm a bleeding edge wh0re after all :)
> -mike

Re: [libdv-dev] cleanup symbols in assembly files

[Mike F. <va...@ge...>]

On Sunday 25 June 2006 04:18, Mike Frysinger wrote:
> a lot of the assembly files define symbols without declaring their types
> ... plus, a lot of the symbols are exported for no good reason

patch ping ...
-mike

Re: [libdv-dev] [patch] add some sanity checks to bootstrap script

[Mike F. <va...@ge...>]

On Sunday 25 June 2006 07:31, Daniel Kobras wrote:
> On Sun, Jun 25, 2006 at 03:45:25AM -0400, Mike Frysinger wrote:
> > simple patch ... if some autotool fails, abort the script, dont just keep
> > running
>
> How about this even simpler version to achieve the same?

patch ping ... Daniel's is pretty simple/obvious :)
-mike

Re: [libdv-dev] Compile error on libdv.

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

> Hi,
>
> I have downloaded libdv from http://libdv.sourceforge.net/, and untar i=
t.
>
> After configure, running compile, I got this error message:
> ----------------------------------
=5B...=5D
> /tmp/ccAu7GAD.s:1464: Error: suffix or operands invalid for =60paddb'
> I am using Open SUSE 10.1 Linux, and gcc version is =22gcc (GCC) 4.1.1.=
=22
>
There are compilation bugfixes in CVS. Please checkout from CVS and tey
it. It is nearly identical to latest release version except for various
build fixes.

[libdv-dev] Compile error on libdv.

[Youngwhan S. <ha...@gm...>]

Hi,

I have downloaded libdv from http://libdv.sourceforge.net/, and untar it.

After configure, running compile, I got this error message:
----------------------------------
make  all-recursive
make[1]: Entering directory `/home/hanmoai/downloads/libdv-0.104'
Making all in libdv
make[2]: Entering directory `/home/hanmoai/downloads/libdv-0.104/libdv'
make  all-am
make[3]: Entering directory `/home/hanmoai/downloads/libdv- 0.104/libdv'
if /bin/sh ../libtool --silent --mode=compile --tag=CC gcc -DHAVE_CONFIG_H
-I. -I. -I..     -g -O2 -Wall -g -MT YUY2.lo -MD -MP -MF ".deps/YUY2.Tpo" -c
-o YUY2.lo YUY2.c; \
then mv -f ".deps/YUY2.Tpo" ".deps/YUY2.Plo"; else rm -f ".deps/YUY2.Tpo";
exit 1; fi
/tmp/ccAu7GAD.s: Assembler messages:
/tmp/ccAu7GAD.s:1464: Error: suffix or operands invalid for `paddb'
/tmp/ccAu7GAD.s:1479: Error: suffix or operands invalid for `paddb'
/tmp/ccAu7GAD.s:1509: Error: suffix or operands invalid for `paddb'
/tmp/ccAu7GAD.s:1524: Error: suffix or operands invalid for `paddb'
/tmp/ccAu7GAD.s:1794: Error: suffix or operands invalid for `paddb'
/tmp/ccAu7GAD.s:1817: Error: suffix or operands invalid for `paddb'
/tmp/ccAu7GAD.s:1844: Error: suffix or operands invalid for `paddb'
/tmp/ccAu7GAD.s:1867: Error: suffix or operands invalid for `paddb'
/tmp/ccAu7GAD.s:2373: Error: suffix or operands invalid for `paddb'
/tmp/ccAu7GAD.s:2388: Error: suffix or operands invalid for `paddb'
/tmp/ccAu7GAD.s:2418: Error: suffix or operands invalid for `paddb'
/tmp/ccAu7GAD.s:2433: Error: suffix or operands invalid for `paddb'
make[3]: *** [YUY2.lo] Error 1
make[3]: Leaving directory `/home/hanmoai/downloads/libdv-0.104/libdv'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/hanmoai/downloads/libdv- 0.104/libdv'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/hanmoai/downloads/libdv-0.104'
----------------------------------
and I added -save-temp option in CFLAGS, and got the source code and attach
with this mail, YUY2.s

Would you check it out what is wrong with that?

I am using Open SUSE 10.1 Linux, and gcc version is "gcc (GCC) 4.1.1."

Thanks.


-- 
Department of Computer Science and Engineering
State University of New York at Buffalo
Buffalo, New York 14260
U.S.A.

Office: T-E9 (716-645-3771)
Email: yw...@cs...

Re: [libdv-dev] [patch] add some sanity checks to bootstrap script

[Mike F. <va...@ge...>]

On Sunday 25 June 2006 07:31, Daniel Kobras wrote:
> On Sun, Jun 25, 2006 at 03:45:25AM -0400, Mike Frysinger wrote:
> > simple patch ... if some autotool fails, abort the script, dont just ke=
ep
> > running
>
> How about this even simpler version to achieve the same?

yes, some people use set -e to accomplish the same thing, it's just been my=
=20
experience that truly portable projects go with '|| exit' instead of 'set -=
e'

either works for me though, i'm a bleeding edge wh0re after all :)
=2Dmike