<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Sergio Garcia Murillo a écrit :
<blockquote cite="mid:BDF3979D32944CE989B11075CCB89D05.MAI@fontventa.es"
type="cite">
<pre wrap="">Hi Borja
ast_write tries to llock the channel and exit if it's not able to do so:
while(ast_channel_trylock(chan)) {
/*cannot goto done since the channel is not locked*/
if(count++ > 10) {
if(option_debug)
ast_log(LOG_DEBUG, "Deadlock avoided for write to channel '%s'\n", chan->name);
return 0;
}
usleep(1);
}
so if you're waiting in the receiver thread in the ast_wait function (with the channel locked) it's very probably
that you will lose the data you're trying to send, that's why I didn't use the ast_write function and called directly
to the tech->write_video .</pre>
</blockquote>
Sergio, I believe that you must use chan_write()<br>
Otherwise, internaal structures of the chan and critical sections of
code will be accessed by more that one thread simultaneously. This may
cause them to be inconsistent. My analysis of the previous deadlock is
that by calling <br>
<pre wrap="">tech->write_video()
directly, it caused the frame queue of local chan to be in an inconsistent state and caused the message counter to be inconsitant then cause the wait_for_n to block.
</pre>
<blockquote cite="mid:BDF3979D32944CE989B11075CCB89D05.MAI@fontventa.es"
type="cite">
<pre wrap=""> In SIP channels i think there was no mayor issue doing it, don't know in zap or misdn
channels. I got problems at hangup because I was trying to write on an non existing function and it crashed.
That's why i would like to write in the receiving thread and signal from the encoding one to get out from ast_wait.
The other question you're wrong, I've developed double buffering already:
/* Get pointer to frame */
bufDecode = vtc->pictures[vtc->picIndex];
</pre>
</blockquote>
Great.<br>
<blockquote cite="mid:BDF3979D32944CE989B11075CCB89D05.MAI@fontventa.es"
type="cite">
<pre wrap="">But I agree that it's not properly protected and could cause some problems on the image. I'll change the behavior of it also.
</pre>
</blockquote>
We need to lock the buffers when one thread is working on it otherwise,
crashes and bugs may appear under load.<br>
<blockquote cite="mid:BDF3979D32944CE989B11075CCB89D05.MAI@fontventa.es"
type="cite">
<pre wrap="">
Best regards
Sergio
----- Original Message -----
From: Borja SIXTO [<a class="moz-txt-link-freetext" href="mailto:borja.sixto@i6net.com">mailto:borja.sixto@i6net.com</a>]
To: <a class="moz-txt-link-abbreviated" href="mailto:borja.sixto@i6net.com">borja.sixto@i6net.com</a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:asterisk-video@lists.digium.com">asterisk-video@lists.digium.com</a>
Sent: Thu, 12 Jun 2008 23:24:56 +0200
Subject: Re: [Asterisk-video] ast_queue_frame: Exceptionally longqueue lengthqueuing to Local/
Hi,
Emmanuel had a great idea last day...
He suspected the direct calling vtc->channel->tech->write_video.
I have replaced this function by an ast_write function and I don't have
locks now.
The ast_write function check the channels locks before calling the write
function.
With the original sources I have a lot of coredumps if I made hard
tests...(calls / hangups frequently).
We think (Emmanuel and I) that the context with the image buffer is not
protected by a lock.
I some cases, we suspect that the context content or the image buffer is
partially overwritten before the sending.
We probably need a dual buffer mode.
In my version (without the thread that schedule the frame rate, all the
processing is generated in the channel thread, so I don't have the
problem for the moment but I don't control the image rate and so the
bandwidth...).
We continue working on it, and thanks to Emmanuel.
Can someone confirm the correction too ?
Regards,
Emmanuel and Borja
Borja SIXTO a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">Hi alls,
Here my contribution to this problem.
I have made a modification in order to disable the thread created to
schedule the fps.
The limitation is that we cannot increase or fine tune the fps.
(the Asterisk channel thread is use to encode/decode too).
So this application don't use new thread creation, but I still having
the locks.
I have added some traces to qualify where the application locks...
I will work on it this week (with Emmanuel).
Regards,
Borja
Sergio Garcia Murillo a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">Hi Emmanuel,
I was working in a problem related issue. I think that the common
problem is that I use a different thread for receiving channel data
and decoding it, and another
different one for encoding and sending. To avoid the locks I have to
call directly to the channel->tech->write which could be causing
serious problems.
I think that the solution would be also move the sending part into
the receiving thread and call ast_write as usual. The problem is that
I don't see a clean way of
signalling from the encoding thread to the ast_wait function in the
receiving thread to wake up and send the data so you don't have to
wait for incoming data to send.
A non-clean way could be to create an internal socket and add it to
the wait function so I can write some dummy data in the enconding
thread to make the decoder thread wake up.
BR
Sergio
Emmanuel BUU escribió:
</pre>
<blockquote type="cite">
<pre wrap="">According to my tests, tt seems that app_transcoder gets into a
deadlock after a few second of operation.
I am trying to identify the issue. It could be related to this issue.
On Mon, 9 Jun 2008 09:58:34 +0200, "Nico Gundacker"
<a class="moz-txt-link-rfc2396E" href="mailto:nico.gundacker@dynetic.de"><nico.gundacker@dynetic.de></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi guys,
as you see at the topic asterisk send out the following warning
message:
[Jun 9 10:47:21] WARNING[25155]: channel.c:916 ast_queue_frame:
Exceptionally long queue length queuing to
Local/1001@menue-vidoestreamen-adbc,2
Sometimes these warning are shown at the screen until the call is
hung up
and sometimes even after call is hung up. Then I need to kill asterisk
process. Is there any solution for this problem?
I used a 3 g phone and the following dial-plan:
..
exten => 101,1,Answer
exten =>
101,2,transcode(,1001@menue-vidoestreamen,h263@qcif/fps=12/kb=52/qmin=4/qmax
=12/gs=50)
...
exten => 1001,1,Answer
exten => 1001,2,rtsp(rtsp://xx.xx.xx.xx/xxxx/xxxx_direkt/28766.3gp)
exten => 1001,3,Goto(0,2)
Thank you for your help
BR Nico
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
--Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a>--
asterisk-video mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-video">http://lists.digium.com/mailman/listinfo/asterisk-video</a>
</pre>
</blockquote>
<pre wrap="">------------------------------------------------------------------------
_______________________________________________
--Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a>--
asterisk-video mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-video">http://lists.digium.com/mailman/listinfo/asterisk-video</a>
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
--Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a>--
asterisk-video mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-video">http://lists.digium.com/mailman/listinfo/asterisk-video</a>
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
--Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a>--
asterisk-video mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-video">http://lists.digium.com/mailman/listinfo/asterisk-video</a></pre>
</blockquote>
<br>
</body>
</html>