[Asterisk-video] app_rtsp: asterisk hangup

[Sergio Garcia]

It could be possible to implement it, but you'll have to drop all the frames
until the next I frame. And if the bandwith is so high you'll end up droping
almost instantaneously the next frames. And even that way the I frame is going
to arrive late and not be synchronized with audio.. 

So if you want to offer any kind of quality service the only option is using 
videos encoded at the best bitrate according it's use. You may even find that
you have to encode the same video at different bitrates for different kind of
access.

BR
Sergio

---------- Original Message ----------------------------------
From: Thomas Frieling <thomas.frieling at viif.de>
Reply-To: Development discussion of video media support in Asterisk<asterisk-video at lists.digium.com>
Date:  Tue, 11 Sep 2007 16:44:52 +0200

>Hi Klaus!
>
>Sounds pretty convincing to me... But if this is really the case, then
>we should definitely handle this problem before it occurs: Maybe we can
>check the queue's size before sending a package and decide to skip some
>packages to synchronize the outgoing stream.
>This would help keeping sound and video synchronous and it would prevent
>the "exceptionally long queue" error.
>
>What do you think about this? Would it be hard to implement?
>
>Greetings,
>Thomas
>
>Am Montag, den 10.09.2007, 09:35 +0200 schrieb Klaus Darilion:
>> Thomas Frieling schrieb:
>> > Hi all!
>> > 
>> > When using app_rtsp with a 3G handset extensively asterisk starts
>> > consuming 100% of the CPU and the following error appears very often
>> > (~80 times a second) on the CLI:
>> > 
>> > [Sep  7 12:52:55] WARNING[11822]: channel.c:924 ast_queue_frame:
>> > Exceptionally long queue length queuing to Local/stream at video-bad8,2
>> > 
>> > Does anyone know what this warning means or where it comes from? Which
>> > logfile should I (or anyone who'd like to) take a look at?
>> 
>> 
>> I guess the framerate received from app_rtsp is bigger then the 
>> framerate received from the h324m connection. Every time h324m_gw reads 
>> a frame from the incoming 64kbit data call, it writes an frame to the 
>> data call too.
>> 
>> Thus if app_rtsp feeds to many frames the queue buffer might grow.
>> 
>> btw: shouldn't the pseudo channel (Local/..) be gone when app_rtsp 
>> answers the call?
>> 
>> regards
>> klaus
>> 
>> _______________________________________________
>> --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
>-- 
>www.ViiF.de - your Mobile Video Community
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>Thomas Frieling - IT Development
>ViiF Mobile Video GmbH, Poststr. 21-22, 10178 Berlin 
>Cell: +49 (0) 173 63 62 62 3
>
>mailto:thomas at ViiF.de
>
>Sitz: Berlin, Amtgericht Berlin-Charlottenburg, HRB: 108350B
>
>Geschäftsführer: Daniel Höpfner, Steffen Brünn
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>_______________________________________________
>--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