Posted: Fri Jun 13, 2008 8:31 am Post subject: [Asterisk-video] ast queue frame: Exceptionally longqueue le
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 . 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];
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.
Best regards
Sergio
----- Original Message -----
From: Borja SIXTO [mailto:borja.sixto@i6net.com]
To: borja.sixto@i6net.com
Cc: asterisk-video@lists.digium.com
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 :
Quote:
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 :
> 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ó:
>> 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"
>> <nico.gundacker@dynetic.de> wrote:
>>
>>> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-video mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-video
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-video mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-video
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum