[Asterisk-video] ast queue frame: Exceptionally longqueue lengthqueuing to Local/
Emmanuel BUU
emmanuel.buu at ives.fr
Fri Jun 13 05:03:16 CDT 2008
Sergio Garcia Murillo a écrit :
> 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 .
Sergio, I believe that you must use chan_write()
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
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.
> 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];
>
>
Great.
> 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.
>
We need to lock the buffers when one thread is working on it otherwise,
crashes and bugs may appear under load.
> 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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> --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 HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-video/attachments/20080613/99006798/attachment-0001.htm
More information about the asterisk-video
mailing list