libdv-dev

Re: [libdv-dev] Fix for severe double-free bug and race condition

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

> videosegment on the state and the bitstream in the dv struct or on the
stack ------------------^

are you subscribed? ...you were not copied on the previous reply.

Re: [libdv-dev] Fix for severe double-free bug and race condition

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

On Wed, 2004-06-02 at 05:03, Johannes Sixt wrote:
> On Mittwoch, 2. Juni 2004 01:51, Dan Dennedy wrote:
> > On Tue, 2004-06-01 at 16:23, Johannes Sixt wrote:
> > > 1. is due to the attempt to remove the malloced memory that is allocated
> > > only once by dv_decode_full_frame (no matter how often the function is
> > > invoked), but a pointer to this memory is kept in dv_decoder_t and freed
> > > each time that dv_decoder_free is invoked. The bogus code was introduced
> > > by a commit on 2003-Oct-29 and the patch essentially reverts some of
> > > that. As a side-effect an unpleasant error path (exit(-1)) is eliminated.
> >
> > dv_decoder_new sets the pointer to null (calloc). The memory is
> > allocated on-demand as you indicated in dv_decode_full_frame. Then, if
> > the pointer is not null, it is free-ed in dv_decoder_free(). You should
> > not call dv_decode_full_frame after calling dv_decoder_free! Also, you
> > can not call dv_decoder_free on the same decoder struct more than once
> > since it frees the struct as well.
> 
> Lets consider a scenario: The application calls dv=dv_decoder_new(...) and
> later dv_decode_full_frame(dv,...). Look at the code:
> 
>   static dv_videosegment_t vs;
>   dv_videosegment_t *seg = &vs;
>   if(!seg->bs) {
>     dv->bs = seg->bs = _dv_bitstream_init();
>     if(!seg->bs)
>       goto no_mem;
>   } /* if */
> 
> seg->bs is 0 at this point, so dv->bs and seg->bs are set to a new bitstream_t
> object.
> Now the applications calls dv_decoder_free(dv): There
> 
>      if (decoder->bs != NULL) free(decoder->bs);
> 
> releases the bitstream_t object. But note that the pointer in static vs inside
> dv_decode_full_frame is not changed!! Now let the application again
> call dv_decoder_new followed by dv_decode_full_frame. Now the code above
> finds seg->bs _not_ 0 and does not allocate a new bitstream_t object. Hence
> all dereferences of seg->bs access already freed memory.

You are correct. I overlooked the if test and all of the screwy stuff
going on with the static videosegment and pointer to it.

> Insofar I find myself corrected that the problem is not a double-free, but
> an access of already freed memory.
> 
> My patch just backs out bs of dv_encoder_t and allocates the bitstream_t
> statically and initializes vs.bs aka seg->bs statically. This way the error
> check can go away, too.
> 
> > > 2. is due to the fact that pthread_mutex_lock is invoked too late.
> > > However, the fix for 1. reduces this race lock to an even smaller window,
> > > but nevertheless it is there and is fixed by the patch.
> >
> > I do see how it will be safer to allocate bitstream on the stack to
> > prevent an unprotected initialisation, but how is static safe for
> > reentrancy? Each thread should have its own decoder struct with its own
> > bitsream to prevent contamination.
> 
> Exactly, exactly, exactly. I would not want the variables static. But I left
> the them so because I investigated the change history and found that revision
> 1.5 of dv.c had the variable vs on the stack, but 4 minutes later you
> commited a version that had vs reverted back to static.
> I concluded that there must be some reason that escapes my comprehension.

When I do light duty maintenance, I tend to try to change as little as
possible, and even though I am one of the last sole maintainers of
libdv, I still consider my participation "light." I do not recall why I
reverted the change except that I saw the way it was before I made
changes and thought there was a good reason for it. So, let us find a
solution that is re-entrant...

> Now assume you wanted to leave the variables static and continue to use
> the mutex (which IMHO is undesirable), the mutex must be moved up before
> the first access of vs. In my version that is just one statement, but in
> the current version it must be before the if statement quoted above
> (and pthread_mutex_unlock must be inserted before the goto no_mem.)

yep, however, the simplest change to make IMO is to just allocate a
bitstream in _new and deallocate it in _free. OTOH...

> > > 3. is due to the use of a mutex in dv_decode_full_frame, which
> > > effectively serializes all calls to this function. The proper fix is to
> > > ditch the mutex and put the static variables on the stack. The patch does
> > > not do this since I don't know whether there are clients which rely on
> > > the current behavior.
> >
> > Yes, the point is to effectively serialise it because there will be
> > image integrity errors without it. I have not analysed the problem
> > enough to determine the exact problem areas (or at least I do not
> > recall). I tried placing mutex locks at deeper places within the call
> > stack, but it had to be at this higher level to protect the image. Are
> > you certain it is as simple as allocating the locals vars of
> > dv_decode_full_frame on the stack?
> 
> Under the assumption that the input to dv_decode_full_frame is the complete
> information of a DV frame (144000 or 120000 bytes) and the output is also
> the complete RGB/YUV/whatever information of the frame and the further
> assumption that a single DV frame is entirely independent from each other,
> yes, I'm certain that it is as simple as allocating the variables on the
> stack (but must use initializers, as in my patch).

Of course, I would love to remove the mutex. However, there are some
globals libdv uses, and I need to make sure they are simply tables and
not stateful.

> As far as the mutex is concerned, my opinion (and obviously also yours) is
> that it can go away since an application is required to have for each
> thread its own dv_decoder_t object.

Well, seeing is believing, and I will make a change to allocate the
videosegment on the state and the bitstream in the dv struct or on the
stack and test it in addition to analysis of globals.

Re: [libdv-dev] Fix for severe double-free bug and race condition

[Johannes S. <joh...@te...>]

On Mittwoch, 2. Juni 2004 01:51, Dan Dennedy wrote:
> On Tue, 2004-06-01 at 16:23, Johannes Sixt wrote:
> > 1. is due to the attempt to remove the malloced memory that is allocated
> > only once by dv_decode_full_frame (no matter how often the function is
> > invoked), but a pointer to this memory is kept in dv_decoder_t and freed
> > each time that dv_decoder_free is invoked. The bogus code was introduced
> > by a commit on 2003-Oct-29 and the patch essentially reverts some of
> > that. As a side-effect an unpleasant error path (exit(-1)) is eliminated.
>
> dv_decoder_new sets the pointer to null (calloc). The memory is
> allocated on-demand as you indicated in dv_decode_full_frame. Then, if
> the pointer is not null, it is free-ed in dv_decoder_free(). You should
> not call dv_decode_full_frame after calling dv_decoder_free! Also, you
> can not call dv_decoder_free on the same decoder struct more than once
> since it frees the struct as well.

Lets consider a scenario: The application calls dv=dv_decoder_new(...) and
later dv_decode_full_frame(dv,...). Look at the code:

  static dv_videosegment_t vs;
  dv_videosegment_t *seg = &vs;
  if(!seg->bs) {
    dv->bs = seg->bs = _dv_bitstream_init();
    if(!seg->bs)
      goto no_mem;
  } /* if */

seg->bs is 0 at this point, so dv->bs and seg->bs are set to a new bitstream_t
object.
Now the applications calls dv_decoder_free(dv): There

     if (decoder->bs != NULL) free(decoder->bs);

releases the bitstream_t object. But note that the pointer in static vs inside
dv_decode_full_frame is not changed!! Now let the application again
call dv_decoder_new followed by dv_decode_full_frame. Now the code above
finds seg->bs _not_ 0 and does not allocate a new bitstream_t object. Hence
all dereferences of seg->bs access already freed memory.

Insofar I find myself corrected that the problem is not a double-free, but
an access of already freed memory.

My patch just backs out bs of dv_encoder_t and allocates the bitstream_t
statically and initializes vs.bs aka seg->bs statically. This way the error
check can go away, too.

> > 2. is due to the fact that pthread_mutex_lock is invoked too late.
> > However, the fix for 1. reduces this race lock to an even smaller window,
> > but nevertheless it is there and is fixed by the patch.
>
> I do see how it will be safer to allocate bitstream on the stack to
> prevent an unprotected initialisation, but how is static safe for
> reentrancy? Each thread should have its own decoder struct with its own
> bitsream to prevent contamination.

Exactly, exactly, exactly. I would not want the variables static. But I left
the them so because I investigated the change history and found that revision
1.5 of dv.c had the variable vs on the stack, but 4 minutes later you
commited a version that had vs reverted back to static.
I concluded that there must be some reason that escapes my comprehension.

Now assume you wanted to leave the variables static and continue to use
the mutex (which IMHO is undesirable), the mutex must be moved up before
the first access of vs. In my version that is just one statement, but in
the current version it must be before the if statement quoted above
(and pthread_mutex_unlock must be inserted before the goto no_mem.)

> > 3. is due to the use of a mutex in dv_decode_full_frame, which
> > effectively serializes all calls to this function. The proper fix is to
> > ditch the mutex and put the static variables on the stack. The patch does
> > not do this since I don't know whether there are clients which rely on
> > the current behavior.
>
> Yes, the point is to effectively serialise it because there will be
> image integrity errors without it. I have not analysed the problem
> enough to determine the exact problem areas (or at least I do not
> recall). I tried placing mutex locks at deeper places within the call
> stack, but it had to be at this higher level to protect the image. Are
> you certain it is as simple as allocating the locals vars of
> dv_decode_full_frame on the stack?

Under the assumption that the input to dv_decode_full_frame is the complete
information of a DV frame (144000 or 120000 bytes) and the output is also
the complete RGB/YUV/whatever information of the frame and the further
assumption that a single DV frame is entirely independent from each other,
yes, I'm certain that it is as simple as allocating the variables on the
stack (but must use initializers, as in my patch).

As far as the mutex is concerned, my opinion (and obviously also yours) is
that it can go away since an application is required to have for each
thread its own dv_decoder_t object.

-- Hannes

Re: [libdv-dev] Fix for severe double-free bug and race condition

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

On Tue, 2004-06-01 at 16:23, Johannes Sixt wrote:
> Hi all,
> 
> libdv suffers from the following deficiencies:
> 
> 1. Double-free of malloced memory in dv_decoder_free.
> 2. Race condition in dv_decode_full_frame.
> 3. Multithreading bottle-neck in dv_decode_full_frame.
> 
> Find attached a patch that fixes 1. and 2.
> 
> 1. is due to the attempt to remove the malloced memory that is allocated only 
> once by dv_decode_full_frame (no matter how often the function is invoked), 
> but a pointer to this memory is kept in dv_decoder_t and freed each time that 
> dv_decoder_free is invoked. The bogus code was introduced by a commit on 
> 2003-Oct-29 and the patch essentially reverts some of that. As a side-effect 
> an unpleasant error path (exit(-1)) is eliminated.

dv_decoder_new sets the pointer to null (calloc). The memory is
allocated on-demand as you indicated in dv_decode_full_frame. Then, if
the pointer is not null, it is free-ed in dv_decoder_free(). You should
not call dv_decode_full_frame after calling dv_decoder_free! Also, you
can not call dv_decoder_free on the same decoder struct more than once
since it frees the struct as well.

> 2. is due to the fact that pthread_mutex_lock is invoked too late. However, 
> the fix for 1. reduces this race lock to an even smaller window, but 
> nevertheless it is there and is fixed by the patch.

I do see how it will be safer to allocate bitstream on the stack to
prevent an unprotected initialisation, but how is static safe for
reentrancy? Each thread should have its own decoder struct with its own
bitsream to prevent contamination.

> 3. is due to the use of a mutex in dv_decode_full_frame, which effectively 
> serializes all calls to this function. The proper fix is to ditch the mutex 
> and put the static variables on the stack. The patch does not do this since I 
> don't know whether there are clients which rely on the current behavior.

Yes, the point is to effectively serialise it because there will be
image integrity errors without it. I have not analysed the problem
enough to determine the exact problem areas (or at least I do not
recall). I tried placing mutex locks at deeper places within the call
stack, but it had to be at this higher level to protect the image. Are
you certain it is as simple as allocating the locals vars of
dv_decode_full_frame on the stack?

[libdv-dev] Fix for severe double-free bug and race condition

[Johannes S. <joh...@te...>]

Hi all,

libdv suffers from the following deficiencies:

1. Double-free of malloced memory in dv_decoder_free.
2. Race condition in dv_decode_full_frame.
3. Multithreading bottle-neck in dv_decode_full_frame.

Find attached a patch that fixes 1. and 2.

1. is due to the attempt to remove the malloced memory that is allocated only 
once by dv_decode_full_frame (no matter how often the function is invoked), 
but a pointer to this memory is kept in dv_decoder_t and freed each time that 
dv_decoder_free is invoked. The bogus code was introduced by a commit on 
2003-Oct-29 and the patch essentially reverts some of that. As a side-effect 
an unpleasant error path (exit(-1)) is eliminated.

2. is due to the fact that pthread_mutex_lock is invoked too late. However, 
the fix for 1. reduces this race lock to an even smaller window, but 
nevertheless it is there and is fixed by the patch.

3. is due to the use of a mutex in dv_decode_full_frame, which effectively 
serializes all calls to this function. The proper fix is to ditch the mutex 
and put the static variables on the stack. The patch does not do this since I 
don't know whether there are clients which rely on the current behavior.

The patch was tested with cinelerra (unofficial CVS version), which crashes 
reliably without the patch.

-- Hannes

Re: [libdv-dev] dvconnect OS/X compile

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

On Sun, 2004-05-30 at 19:32, Steven M. Schultz wrote:
> > #if _POSIX_MEMLOCK > 0
> > ...
> > #endif
> 
> 	Is it OK to use "#ifdef _POSIX_MEMLOCK" instead?   If so, then the
> 	attached patch will do the job.

I am not sure that will be a strict enough test. I am committing the #if
>0 version.

Re: [libdv-dev] dvconnect OS/X compile

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

On Sun, 30 May 2004, Dan Dennedy wrote:

> AVAILABILITY
>    On  POSIX  systems  on  which  mlockall  and  munlockall are available,

	
> I assumed some posix compliance was enough, but was lazy to add the
> check to _POSIX_MEMLOCK. Try enclosing the if..else blocks inside:

	It sounds like it's an optional feature - at least that's how I
	read the "on POSIX systems on which mlockall ... are available".

> #if _POSIX_MEMLOCK > 0
> ...
> #endif

	Is it OK to use "#ifdef _POSIX_MEMLOCK" instead?   If so, then the
	attached patch will do the job.

	Cheers,
	Steven Schultz

Re: [libdv-dev] dvconnect OS/X compile

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

I did that.

>From the man page here:

AVAILABILITY
       On  POSIX  systems  on  which  mlockall  and  munlockall are
available,
       _POSIX_MEMLOCK is defined in <unistd.h> to a value greater than
0. (See
       also sysconf(3).)
 
CONFORMING TO
       POSIX.1b, SVr4.   

I assumed some posix compliance was enough, but was lazy to add the
check to _POSIX_MEMLOCK. Try enclosing the if..else blocks inside:
#if _POSIX_MEMLOCK > 0
...
#endif

On Sun, 2004-05-30 at 14:15, Steven M. Schultz wrote:
> Hi -
> 
> 	libdv used to compile w/o errors, but it seems dvconnect has
> 	recently changed and the compile fails with:
> 
> if gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -Wall -g -MT dvconnect.o -MD -MP -MF ".deps/dvconnect.Tpo" \
>   -c -o dvconnect.o `test -f 'dvconnect.c' || echo './'`dvconnect.c; \
>   then mv -f ".deps/dvconnect.Tpo" ".deps/dvconnect.Po"; \
>   else rm -f ".deps/dvconnect.Tpo"; exit 1; \
>   fi
>   dvconnect.c: In function `main':
>   dvconnect.c:1072: warning: implicit declaration of function `mlockall'
>   dvconnect.c:1072: error: `MCL_CURRENT' undeclared (first use in this function)
>   dvconnect.c:1072: error: (Each undeclared identifier is reported only once
>   dvconnect.c:1072: error: for each function it appears in.)
>   dvconnect.c:1072: error: `MCL_FUTURE' undeclared (first use in this function)
>   gmake[2]: *** [dvconnect.o] Error 1
> 
> 	I'll look into it and see if I can come up with some #ifdefs that'll
> 	take care of things.
> 
> 	Cheers,

[libdv-dev] dvconnect OS/X compile

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

Hi -

	libdv used to compile w/o errors, but it seems dvconnect has
	recently changed and the compile fails with:

if gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -Wall -g -MT dvconnect.o -MD -MP -MF ".deps/dvconnect.Tpo" \
  -c -o dvconnect.o `test -f 'dvconnect.c' || echo './'`dvconnect.c; \
  then mv -f ".deps/dvconnect.Tpo" ".deps/dvconnect.Po"; \
  else rm -f ".deps/dvconnect.Tpo"; exit 1; \
  fi
  dvconnect.c: In function `main':
  dvconnect.c:1072: warning: implicit declaration of function `mlockall'
  dvconnect.c:1072: error: `MCL_CURRENT' undeclared (first use in this function)
  dvconnect.c:1072: error: (Each undeclared identifier is reported only once
  dvconnect.c:1072: error: for each function it appears in.)
  dvconnect.c:1072: error: `MCL_FUTURE' undeclared (first use in this function)
  gmake[2]: *** [dvconnect.o] Error 1

	I'll look into it and see if I can come up with some #ifdefs that'll
	take care of things.

	Cheers,
	Steven Schultz

Re: [libdv-dev] other language bindings

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

On Sat, 2004-05-29 at 19:14, Roman Shaposhnick wrote:
> On Sat, May 29, 2004 at 05:03:10PM -0400, Lex Stein wrote:
> > 
> > Hi, Do there exist bindings for libdv routines for languages
> > other than C? For example, Perl, Python, or OCaml.
> 
>   Not that I know of, but you can try ffmpeg's DV codec for that.
>   FFmpeg(libavcodec) has been wrapped in tons of stuff including
>   Python and Java.

I second this suggestion.

Re: [libdv-dev] other language bindings

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

On Sat, May 29, 2004 at 05:03:10PM -0400, Lex Stein wrote:
> 
> Hi, Do there exist bindings for libdv routines for languages
> other than C? For example, Perl, Python, or OCaml.

  Not that I know of, but you can try ffmpeg's DV codec for that.
  FFmpeg(libavcodec) has been wrapped in tons of stuff including
  Python and Java.

Thanks,
Roman.

[libdv-dev] other language bindings

[Lex S. <st...@ee...>]

Hi, Do there exist bindings for libdv routines for languages
other than C? For example, Perl, Python, or OCaml.

Thanks,
Lex

[libdv-dev] the utilities

[Lex S. <st...@ee...>]

Hi, There are a bunch of interesting-looking utilities bundled with
the libdv distribution (dovlc, gasmoff, reppm, testvlc, for example).
Is there a way of finding out what these do, other than reading through
the source? Any documentation, perhaps?

Thanks, Lex

Re: [libdv-dev] why pkgconfig ?

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

On Sat, 2004-05-29 at 01:45, Lex Stein wrote:
> Hi, Why does libdv need pkgconfig? This is a real hassle anytime
> I need to install libdv. Thanks, Lex
> 
> checking for pkg-config... /usr/bin/pkg-config
> checking for glib >= 1.2.4 gtk+ >= 1.2.4... sh: line 1: glib-config: command not found
> sh: line 1: glib-config: command not found
> sh: line 1: glib-config: command not found
> sh: line 1: glib-config: command not found
> sh: line 1: glib-config: command not found
> sh: line 1: glib-config: command not found
> Requested 'glib >= 1.2.4' but version of GLib is
> 
> configure: error: Library requirements (glib >= 1.2.4 gtk+ >= 1.2.4) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find t

Well, your problem is not due to pkg-config, it is due to a missing
glib/gtk. pkg-config is required to get the compiler options required to
link to glib. When building libdv, try 'configure --disable-gtk'.
However, if you do, then you will not get the playdv utility.

[libdv-dev] why pkgconfig ?

[Lex S. <st...@ee...>]

Hi, Why does libdv need pkgconfig? This is a real hassle anytime
I need to install libdv. Thanks, Lex

checking for pkg-config... /usr/bin/pkg-config
checking for glib >= 1.2.4 gtk+ >= 1.2.4... sh: line 1: glib-config: command not found
sh: line 1: glib-config: command not found
sh: line 1: glib-config: command not found
sh: line 1: glib-config: command not found
sh: line 1: glib-config: command not found
sh: line 1: glib-config: command not found
Requested 'glib >= 1.2.4' but version of GLib is

configure: error: Library requirements (glib >= 1.2.4 gtk+ >= 1.2.4) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find t

Re: [libdv-dev] Is libdv thread safe?

[David T. <to...@vi...>]

Dan Dennedy wrote:

>The lib is not purely thread safe, but since Kino is multithreaded, I
>added a mutex lock to an appropriate place in the libdv decoder. Note,
>however, in general, concerns over thread safetiness really only apply
>to multiple threads accessing a lib at the same time--not just the usage
>of a lib in a multithreaded program. For example, while Kino is playing
>a video, it must update its thumbnails in the storyboard on a separate
>thread. Or, the Kino FX can render in the background (decode and
>encode), and you can play a video in the foreground (decode). Those are
>examples where libdv is working just fine today in a multithreaded
>multiuse environment.
>
>It's been a while since I ran into X11 async errors in order to help
>you.
>
Yeah, me too.  It seems to be some kind of libdv + gtk + X thing.  As I 
said, I recall having this problem a couple of years back with V4L too.  
But the gtk_threads() functions solved that.  So there must be something 
naughty inside libdv somewhere.  Do you use GTK for Kino?

I also have things threaded out similarly.  The video reading thread is 
carried out in a separate thread ... wheras the GTK drawing and whatnot 
is done separately, and protected with gtk_threads() calls.

Ugh.  This is a showstopper.

DT


>
>On Tue, 2004-05-25 at 16:39, David Topper wrote:
>  
>
>>I have some code that uses either V4L or libdv to grab video.  With V4L, 
>>there'ets no problem.  But with libdv, however, I get the following 
>>error after my app runs for 30 seconds or so:
>>
>> Xlib: unexpected async reply (...)
>>
>>I got this message years ago with V4L, but putting in the appropriate 
>>hooks (eg., gdk_threads_enter(), mutex locks) and the like eliminated 
>>the problem.  Since it's cropping up again, I can only assume there's 
>>something inside libdv that's not behaving nicely with threads.
>>
>>Is there some compile or #define option I can turn on to make the 
>>libraries thread safe?
>>
>>Thanks,
>>
>>DT
>>    
>>

Re: [libdv-dev] Is libdv thread safe?

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

The lib is not purely thread safe, but since Kino is multithreaded, I
added a mutex lock to an appropriate place in the libdv decoder. Note,
however, in general, concerns over thread safetiness really only apply
to multiple threads accessing a lib at the same time--not just the usage
of a lib in a multithreaded program. For example, while Kino is playing
a video, it must update its thumbnails in the storyboard on a separate
thread. Or, the Kino FX can render in the background (decode and
encode), and you can play a video in the foreground (decode). Those are
examples where libdv is working just fine today in a multithreaded
multiuse environment.

It's been a while since I ran into X11 async errors in order to help
you.

On Tue, 2004-05-25 at 16:39, David Topper wrote:
> I have some code that uses either V4L or libdv to grab video.  With V4L, 
> there'ets no problem.  But with libdv, however, I get the following 
> error after my app runs for 30 seconds or so:
> 
>  Xlib: unexpected async reply (...)
> 
> I got this message years ago with V4L, but putting in the appropriate 
> hooks (eg., gdk_threads_enter(), mutex locks) and the like eliminated 
> the problem.  Since it's cropping up again, I can only assume there's 
> something inside libdv that's not behaving nicely with threads.
> 
> Is there some compile or #define option I can turn on to make the 
> libraries thread safe?
> 
> Thanks,
> 
> DT

Re: [libdv-dev] Is libdv thread safe?

[David T. <to...@vi...>]

David Topper wrote:

> I have some code that uses either V4L or libdv to grab video.  With 
> V4L, there'ets no problem.  But with libdv, however, I get the 
> following error after my app runs for 30 seconds or so:
>
> Xlib: unexpected async reply (...)
>
> I got this message years ago with V4L, but putting in the appropriate 
> hooks (eg., gdk_threads_enter(), mutex locks) and the like eliminated 
> the problem.  Since it's cropping up again, I can only assume there's 
> something inside libdv that's not behaving nicely with threads.
>
> Is there some compile or #define option I can turn on to make the 
> libraries thread safe?


BTW:  seems much more stable when compiled with --disable-asm ... so I'm 
wondering if some of that code might be breaking thread safety?

DT

-- 
Technical Director - Virginia Center for Computer Music
http://www.virginia.edu/music/vccm.html

[libdv-dev] Is libdv thread safe?

[David T. <to...@vi...>]

I have some code that uses either V4L or libdv to grab video.  With V4L, 
there'ets no problem.  But with libdv, however, I get the following 
error after my app runs for 30 seconds or so:

 Xlib: unexpected async reply (...)

I got this message years ago with V4L, but putting in the appropriate 
hooks (eg., gdk_threads_enter(), mutex locks) and the like eliminated 
the problem.  Since it's cropping up again, I can only assume there's 
something inside libdv that's not behaving nicely with threads.

Is there some compile or #define option I can turn on to make the 
libraries thread safe?

Thanks,

DT

-- 
Technical Director - Virginia Center for Computer Music
http://www.virginia.edu/music/vccm.html

[libdv-dev] Good old - Xlib: unexpected async reply (sequence 0x53319)! again

[David T. <to...@vi...>]

I ran into this a few years back when using V4L and Gtk.  I thought I 
had it licked by putting gdk_threads_enter() into my code.   Now I'm 
working with libdv and the error is cropping up again.  I've tried 
adding XinitThreads() but then when I go to change the value in a text 
entry box, my app freezes.  But w/o the XinitThreads() call my app 
freezes with the aforementioned error.  Anyone know how to solve this?

I'm running kernel 2.4.22 with X 4.3.0 (using the ATI accelerated server 
for th Radeon 9600) and GTK 1.2.10.

Anyone have a clue?

Thanks,

DT

-- 
Technical Director - Virginia Center for Computer Music
http://www.virginia.edu/music/vccm.html

[libdv-dev] DV reading working!!! Question about quality

[David T. <to...@vi...>]

Hi all,

Thanks for putting me on the right path.  I basically hacked up some 
code grabbed from playdv to do my DV reading (mmaping still doesn't 
work) but it runs fine in non_mmaped mode.  So I can work out the 
details later.

One quick question, where does:

  dv_player->decoder->quality = dv_player->decoder->video->quality;

get set initially?  I'm using the same technique, and was initially 
getting B&W image w/ very low resolution.  So I simply hacked it, 
(setting it to 5) and everything is fine.

Strange that playdv would set it to one thing, and my app (which uses 
the same code) would set it to something else?

DT

-- 
Technical Director - Virginia Center for Computer Music
http://www.virginia.edu/music/vccm.html

[libdv-dev] Error in playdv code?

[David T. <to...@vi...>]

I may be totally off here but shouldn't lines 189-192:

 no_decoder:
  free(result->oss);
 no_oss:
  free(result->display);

read as follows:

 no_decoder:
  free(result->display);
 no_oss:
  free(result->oss);

??

DT
-- 

Technical Director - Virginia Center for Computer Music
http://www.virginia.edu/music/vccm.html

Re: [libdv-dev] Playdv image problems + ...

[David T. <to...@vi...>]

Stefan Lucke wrote:

>On Freitag, 21. Mai 2004 00:55, David Topper wrote:
>
>  
>
>>image (correct) and an Xv grab of playdv output.  Anyone recognize this 
>>problem?
>>
>>    http://presto.music.virginia.edu/topper/libdv.html
>>    
>>
>
>Looks like either the image is damaged and or PAL/NTSC is detected false
>(one macroblock).
>
>Any error messages during decode ? Used libdv version number ?
>
No error messages.  I was using libdv-0.99.  Just installed v .102 and 
it runs fine now.

Thanks,

DT

Re: [libdv-dev] Playdv image problems + ...

[David T. <to...@vi...>]

Dan Dennedy wrote:

>On Thu, 2004-05-20 at 18:55, David Topper wrote:
>  
>
>>Just testing out playdv here, as it seems like the de-factor source code 
>>example for using libdv.  But I'm already having some trouble with 
>>playdv.  Basically, the image is garbled.  Attached is a kino still 
>>image (correct) and an Xv grab of playdv output.  Anyone recognize this 
>>    
>>
>
>playdv was using Xv? You cannot get a screen capture of an Xv image.
>Besides that point, you are claiming that the stock playdv looks like
>the image you posted?
>
No, I had it using GTK.  Yes, the garbled image is from playdv.  This is 
on a 3.2ghz system with an ATI Radeon 9600 video card.

>To me, that looks like a buffer alignment issue as well as some missing
>DV packets. Are you writing your own DV capture code? If so, perhaps
>there is a problem there. Does Kino playback correctly what you
>captured? A word of caution about reading raw DV from dv1394... you must
>
No, that was an image from the stock playdv output.  Yes, Kino capture 
image is just fine (that's what the other image is).

>take care to minimise any latency in the fetching and releasing of
>dv1394 buffers. Failure to do so may cause frame corruption with pieces
>of one frame showing up in another frame due to buffer overruns. I tried
>to prevent this completely within dv1394, but failed and never fixed
>it--that part of the code's kinda painful to work with, and there is a
>new way to capture now anyways.
>
New way to capture?

>It is hard to tell exactly what you are attempting and doing. You want
>to write your own code for DV capture using dv1394 and playback using
>libdv and Xv, GDK, SDL, or other?
>
Yeah, I just want to grab a nice [x][y] array, display it in a GTK 
window, and do various motion / image detection algorithms on the array.

DT

Re: [libdv-dev] Playdv image problems + ...

[Stefan L. <st...@lu...>]

On Freitag, 21. Mai 2004 00:55, David Topper wrote:

> image (correct) and an Xv grab of playdv output.  Anyone recognize this 
> problem?
> 
>     http://presto.music.virginia.edu/topper/libdv.html

Looks like either the image is damaged and or PAL/NTSC is detected false
(one macroblock).

Any error messages during decode ? Used libdv version number ?

> 
> Also, I don't see any specific code inside playdv that handles the 
> YUV411-RGB24 conversion, but it surely must as it renders a gtk window 
> with the good old gdk_draw_rgb_image().  I'm doing that too, but am 
> obviously missing a conversion routine.

file libdv/rgb.c.


-- 
Stefan Lucke