[Asterisk-video] ast_queue_frame: Exceptionally long queue lengthqueuing to Local/
Borja SIXTO
borja.sixto at i6net.com
Tue Jun 10 16:16:00 CDT 2008
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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: app_transcoder.c
Url: http://lists.digium.com/pipermail/asterisk-video/attachments/20080610/5b42508c/attachment-0001.txt
More information about the asterisk-video
mailing list