[Asterisk-video] ast queue frame: Exceptionally longqueue lengthqueuing to Local/
Sergio Garcia Murillo
sergio.garcia at fontventa.com
Fri Jun 13 04:25:06 CDT 2008
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 at i6net.com]
To: borja.sixto at i6net.com
Cc: asterisk-video at 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 :
> 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 at 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 at 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 at menue-vidoestreamen,h263 at 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--
asterisk-video mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-video
More information about the asterisk-video
mailing list