[Asterisk-video] h324m_handshake (was: app_mp4 fixed video playback)

[Sergio Garcia]

It's been a quite busy weekend, but I managed to commit some changes (as probably you already know).

What I did is:
-Modify ligh324m to correctly set call state and implment h245 fastvideoupdate
-Modify app_h324 in two ways, h324m_gw monitor 3g call state and send a VIDUPDATE
when it's stablisehd and add h324m_gw_answer that answer the local pseudo channel and
waits the VIDUPDATE.
-Modify the app_mp4 to make mp4save send a VIDUPDATE when started.

So i think that in the case of a 3g call to app_mp4 is almost everything corrected.
When the call is received the local channel is created, and answered with h324m_gw_answer which waits for the h245 completiong (by waiting for VIDUPDATE). 
When the negotiation is completed both channels start simultaneously, so no media data is lost and you get the first I frame from mp4play and mp4save can record also the first I Frame from the phone.

In case of for, example, running a mp4play before an mp4save, you will be starting recording at a randon rtp packet. This case is partially handled by sending the VIDUPDATE to the 3G phone so it will send you an IFRAME as soon as possible.
I've been also thinking in the posibility of not start recording until the first I Frame is recieved so the mp4 could be played back perfectly. As the user would have to wait a random time until his phone sends the I Frame (or even worse in a SIP client) the user has to signalled someway when the recording starts.
The solution i have thougth of is dumping all media until I got a good I frame start, and then signall it to the user by looping his image back, so he can know when the system has started the recording.. what do u think about???

The case of 3G calling to a sip phone is a bit more complicated, the 3g call is received and the dial is launched in the pseudo channel. When the sip client answer it start sending audio and video (which is going to be lost) and receiving no data and the h245 negotiation begins.
When the 3G call is correctly negotiated and the media is correctly bridged to the sip client and it recieves correctly firs phone I frame. The problem is, again, the 3g phone will start receiving the sip client video from a random point and the video will be mangled till the sip client decides to send another iframe. 

Should think better the last case to get a good solution..

BR
Sergio



---------- Original Message ----------------------------------
From: Klaus Darilion <klaus.mailinglists at pernau.at>
Reply-To: Development discussion of video media support in Asterisk<asterisk-video at lists.digium.com>
Date:  Mon, 03 Sep 2007 16:22:54 +0200

>Hi Sergio!
>
>The more I think about it I think it better you choose your approach by 
>not modifying app_h324 but instead having a generic Asterisk application 
>WaitForMedia().
>
>This application answers the call (if not already answered) and waits 
>for at least one video frame (or a certain control frame, this should be 
>configurable by options). Then the function returns. Of course it would 
>be good if this first video frame will be forwarded too.
>
>What do you think about it?
>
>regards
>klaus
>
>
>Sergio Garcia schrieb:
>> ---------- Original Message ----------------------------------
>> From: Klaus Darilion <klaus.mailinglists at pernau.at>
>> Reply-To: Development discussion of video media support in Asterisk<asterisk-video at lists.digium.com>
>> Date:  Fri, 31 Aug 2007 08:11:02 +0200
>>>
>>> Sergio Garcia schrieb:
>>>  > The problem is that I don't want to answer the phone without knowing
>>>> if there is anyone at the other side. The idea I have is implment an
>>>> h324m_gw_answer that answer the channel and wait for a control
>>>> command (probably AST_CONTROL_VIDUPDATE) to return control..
>>> What about options for h324m_gw, e.g.:
>>>  'a': answer the incoming call immediately. This is
>>>       useful in video applications where the incoming
>>>       call will be answered for sure.
>>>
>>>  'w': wait for H245 channel negotiation. When using this option,
>>>       h324m_gw starts the pseudo channel after H245 handshake. Thus,
>>>       the pseudo channel can start playback of audio and video
>>>       immediately without loosing frames. Note: 'w' implies 'a'
>> 
>> That could be another option, but the  I don't see "a" option it. 
>> I mean, I don't see in which case you would like to answer the phone without
>> waiting for the h245 to finish. 
>> The only case I would be if you have something that is not instant in the local
>> channel (like for example grabbing caller user data) that would take a few seconds
>> so you want to run the h245 negotiation and the user data process in parallel.
>> But then you'll have to synchronize both channels for waiting each other..
>> 
>> Perhaps a mixed solution could be good here.. and implementing a AST_CONTROL_VIDUPDATE
>> to signal the 3g phone is also somehting that we need.. 
>> 
>> BR
>> Sergio
>>  
>> 
>> _______________________________________________
>> --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
>