Jérôme WAGNER wrote:
Hello,

Please all note that we have a problem with the wtimer lib (sometimes called
libtimer).

It should be modified in order to add a blocking stopTimer function.

The stopTimer should block until all callbacks called by the timer are
finished executing.

Under windows, this needs some work because because the mmtimer API says
that the stopTimer function guarantees that no callback will be called after
that function ; not that the called callbacks are finished.

This problem was leading to a crash upon stopping a call, because the call
is stopped.

Some other threading sync mechanism could be put in place but this "closing
timer" problem is a real thing that needs to be solved before using wtimer
again.

Jérôme
  
This is pretty easy to solve... It is suffeicent to have a global InCallback counter inceremented upon
entry into the callback and decermeneted upon exit....
When stooping the video streaming  one should cancel the timers and then sleep in loop untel the counter becomes zero....

Vadim






-----Message d'origine-----
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] De la part de Philippe
BERNERY
Envoyé : vendredi 7 juillet 2006 18:07
À : Vadim Lebedev
Cc : wengophone-devel
Objet : Re: [Wengophone-devel] V4L webcam support in NG and classic

The code for managing the webcam on linux is based on an older  
version of Classic. The Classic algorithm has then be changed to use  
timers which is a better approach.
This code should be changed to use the last Classic/timer approch. I  
created the ticket #809 ( http://dev.openwengo.com/trac/openwengo/ 
trac.cgi/ticket/809) for this task.

Thanks for your report Matthias.

--
Philippe Bernery

  
Matthias Schneider wrote:

      
Hi all,
comparing the V4L implementation of Wengophone classic (libs/ 
webcam/src/v4l-driver/WebcamV4l.cpp)
and NG (libs/webcam/src/v4l/V4LWebcamDriver.cpp) I noticed a  
completely different architecture.
While classic makes use of a timer in order to trigger the  
capturing of a frame, the NG driver
consists of a loop that sleep for 1/fps seconds and then captures  
a frame. This rather simple
approach raises problems when trying to use higher frame rates  
(e.g. desired framerate = 25 fps,
resulting in a sleep of 40ms - however an additional execution  
time of 20 ms of the rest of the
loop results in a loop interval of 60ms on my machine, lowering  
the framerate to a jittery 15
fps).

I would like to ask about the motivation of leaving the more  
sophisticated (classic) approach in
favor of the new implementation which is not really usable for  
high bitrates and quite
undeterministic.

Thanks in advance
Matthias Schneider

        

_______________________________________________
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel




  

_______________________________________________
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel

Reply via email to