Posted: Fri Jun 13, 2008 9:42 am Post subject: [Asterisk-video] ast queue frame: Exceptionally longqueuelen
Hi Emmanuel,
I'm with you that using tech->write directly is not a good idea, but using ast_write on the encoder thread is not
the good solution also. In fact I think that the best solution would be using one thread for decoding, one for
encoding and the main one for sending and receiving. I would have to implement some kind of self-connected
socket to be able to pass it to the ast_wait function and be able to signal from the encoder thread to get out
of it and send the frame.
I don't agree with you on the second part, simultaneous read/write on the image buffer wont cause a crash in
any case, only bad encoded image.
Best regards
Sergio
----- Original Message -----
From: Emmanuel BUU [mailto:emmanuel.buu@ives.fr]
To: asterisk-video@lists.digium.com
Sent: Fri, 13 Jun 2008 12:03:16 +0200
Subject: Re: [Asterisk-video] ast queue frame: Exceptionally longqueuelengthqueuing to Local/
Sergio Garcia Murillo a écrit :
Quote:
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.
Quote:
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.
Quote:
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.
Quote:
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 :
> 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