[Asterisk-video] Videomixing in MeetMe + testing grandstream

dave cantera david.cantera at iacnet.net
Thu Jun 21 14:02:30 CDT 2007


lorenzo,
at this time, I don't have a server available to load the framework.  I 
probably can provide a phone, I just received an extra one in.  I 
haven't checked it out yet, they are supposed to support h.263 and 
h.264.  the older version only supported 264.
let me know if that helps.  possibly in a few weeks I may have a server 
freed up as we are setting up a new collocation and restructuring things.
thanks,
daveC

Lorenzo Miniero wrote:
> Hi Dave,
>
> in these days I've been talking with a person who has tried the mixer 
> with two GrandStream GXV3000 phones. These have been the results with 
> Confiance's VideoMixer (I don't know if Sergio's mixer works fine with 
> them, I'll leave the answer to him):
>
> 	* normally, the mixing worked, but he only could see the upper left 
> part of the video: this was probably because of the fact that the phone 
> negotiated a CIF resolution, while my mixer only handles QCIF at the 
> moment, and so the blitting phase was incorrect;
>
> 	* starting from that, I tried suggesting him to change the global 
> variables that set the sizes to 176x144; I thought this could work, 
> since all frame manipulation is handled according to these variables, 
> but it didn't, the phones didn't receive any video at all;
>
> 	* I then tried changing the payload header for H.263, since its SRC 
> field was statically set to 010 (QCIF), but changing it to 011 (CIF) 
> didn't solve the issue at all.
>
> So, the answer for now is that the mixer doesn't work as it should with 
> them at the moment. It is probably related to the encoder settings for 
> higher resolutions and with the payload header for the codec: however, I 
> don't have any Grandstream in my hands currently, so I can't check what 
> could be wrong. I frankly don't even know which codecs it supports, 
> which resolutions/fps/bitrates etc and which modes for the payload 
> header. So if some of you could install the framework somewhere on your 
> servers and make some test yourself, your feedback would be of great 
> help and much appreciated.
>
> Regards,
> Lorenzo
>
>
> dave cantera ha scritto:
>   
>> lorenzo,
>> I didn't see anyone testing with a grandstream videophone.  if we can 
>> schedule a time for testing on your server(s), I have two that I can use 
>> to test with for compatibility issues if you want....   just let me know 
>> and we'll find a time when we can hookup.
>> daveC
>>
>> Lorenzo Miniero wrote:
>>     
>>> Hi Klaus,
>>>
>>> I'm glad you got the mixer working!
>>> My answers to your comments are inline.
>>>
>>>
>>>  
>>>       
>>>> HI Lorenzo  - this fix works. Thus, I got mixed video. Below some 
>>>> comments:
>>>>
>>>> - I have lots of troubles with eyebeam when video is activated. 
>>>> System and eyebeam need lots of CPU resource and I can't do anything 
>>>> else on my PC.
>>>>     
>>>>         
>>> Is it always so with eyebeam+video (with any other video call you have 
>>> with
>>> anyone), or only when eyebeam receives the frames from the mixer?
>>>
>>>
>>>  
>>>       
>>>> - ffmpeg reports some compilation problems when started - do you know 
>>>> how to solve this?
>>>>
>>>> Compiler did not align stack variables. Libavcodec has been miscompiled
>>>> and may be very slow or crash. This is not a bug in libavcodec,
>>>> but in the compiler. Do not report crashes to FFmpeg developers.
>>>>     
>>>>         
>>> I frankly don't know what may cause this. You could try a make clean and
>>> reconfigure/recompile/reinstall ffmpeg to see it gets fixed this way.
>>>
>>>
>>>  
>>>       
>>>> - There are lots of ffmpeg error messages during mixing:
>>>>
>>>> -- this one happens always - even if there is only one, deactiated 
>>>> peer and the logo is sent out:
>>>> [h263 @ 0xb7de8ca0]vbv buffer overflow
>>>> [h263 @ 0xb7de8ca0]vbv buffer overflow
>>>> [h263 @ 0xb7de8ca0]vbv buffer overflow
>>>> [h263 @ 0xb7de8ca0]vbv buffer overflow
>>>> [h263 @ 0xb7de8ca0]vbv buffer overflow
>>>> ....
>>>>     
>>>>         
>>> Yes, I noticed this too. I think it's related to rate control and to 
>>> the fact
>>> that the logo is a fixed frame (i.e. no motion), but I still couldn't
>>> understand how to handle this.
>>>
>>>
>>>  
>>>       
>>>> -- this one happens very often during mixing
>>>> [h263 @ 0xb7de8ca0]I cbpc damaged at 0 4
>>>> [h263 @ 0xb7de8ca0]Error at MB: 164
>>>> [h263 @ 0xb7de8ca0]I cbpc damaged at 0 8
>>>> [h263 @ 0xb7de8ca0]Error at MB: 328
>>>> [h263 @ 0xb7de8ca0]I cbpc damaged at 0 12
>>>> [h263 @ 0xb7de8ca0]Error at MB: 492
>>>> [h263 @ 0xb7de8ca0]I cbpc damaged at 0 16
>>>> [h263 @ 0xb7de8ca0]Error at MB: 656
>>>> [h263 @ 0xb7de8ca0]I cbpc damaged at 0 20
>>>> [h263 @ 0xb7de8ca0]Error at MB: 820
>>>> [h263 @ 0xb7de8ca0]I cbpy damaged at 0 24
>>>> [h263 @ 0xb7de8ca0]Error at MB: 984
>>>> [h263 @ 0xb7de8ca0]concealing 609 DC, 609 AC, 609 MV errors
>>>> [h263 @ 0xb7de8ca0]Bad picture start code
>>>> [h263 @ 0xb7de8ca0]header damaged
>>>> ...
>>>> [h263 @ 0xb7de8ca0]concealing 707 DC, 707 AC, 707 MV errors
>>>> [h263 @ 0xb7de8ca0]Bad picture start code
>>>> [h263 @ 0xb7de8ca0]header damaged
>>>> [h263 @ 0xb7de8ca0]vbv buffer overflow
>>>> [h263 @ 0xb7de8ca0]I cbpc damaged at 0 4
>>>> [h263 @ 0xb7de8ca0]Error at MB: 164
>>>> [h263 @ 0xb7de8ca0]I cbpc damaged at 0 8
>>>> [h263 @ 0xb7de8ca0]Error at MB: 328
>>>> [h263 @ 0xb7de8ca0]I cbpc damaged at 0 12
>>>> [h263 @ 0xb7de8ca0]Error at MB: 492
>>>> [h263 @ 0xb7de8ca0]I cbpc damaged at 0 16
>>>> [h263 @ 0xb7de8ca0]Error at MB: 656
>>>> [h263 @ 0xb7de8ca0]I cbpc damaged at 0 20
>>>> [h263 @ 0xb7de8ca0]Error at MB: 820
>>>> [h263 @ 0xb7de8ca0]I cbpc damaged at 0 24
>>>> [h263 @ 0xb7de8ca0]Error at MB: 984
>>>> ...
>>>>     
>>>>         
>>> This could be related to two aspects:
>>>
>>>         * the H.263 codec used by eyebeam could be not-100%-compliant 
>>> with the
>>> ffmpeg H.263 codec (and this is something we'd have to live with);
>>>         * there might be problems with the H.263 payload header and 
>>> how I handle
>>> it.
>>>
>>> I'm still investigating the H.263 payload header issue, also 
>>> considering that
>>> there are three different modes for it. In fact, different settings give
>>> different results according to the client (for example, a setting that 
>>> works
>>> fine with our client gives strange behaviour with Wengophone, while 
>>> settings
>>> that work fine with Wengophone don't work at all with our client, and 
>>> the same
>>> applies with some other clients we tested). I'll try eyebeam myself as 
>>> soon as
>>> I can to see if I can sort it out. Of course, if you have advices for 
>>> this, let
>>> me know!
>>>
>>>
>>>  
>>>       
>>>> - I tested with 2 peers, thus the video was split into two parts 
>>>> (left/right). One video source was shrunk (as it should be), but the 
>>>> other source was enlarged (zoomed in): I found out that the enlarged 
>>>> video had different settings in xlite. After setting bandwidth in 
>>>> xlite from "Fast Cable ..." to "DSl, Cable..." it worked fine.
>>>>     
>>>>         
>>> Considering how the layout for two sources is codec in the mixer, both 
>>> the
>>> videos should be shrunk (in all other layouts, sources are almost 
>>> always simply
>>> resized). The fact that changing bandwidth gave the expected result 
>>> might imply
>>> a fps-related issue: in fact, the mixer currently uses a fixed 
>>> outgoing fps, so
>>> very different in-fps and out-fps might explain this...
>>>
>>>
>>>  
>>>       
>>>> - If the videomixer is restarted, Asterisk fails to reconnect to the 
>>>> videomixer.
>>>>     
>>>>         
>>> Yes, the integration is very rough at the moment, since all is 
>>> work-in-progress.
>>> I focused on the mixing aspects, and still didn't take care of 
>>> reconnections
>>> and so on. If Asterisk fails at connecting to the videomixer at boot, 
>>> or the
>>> connection gets lost, there's no way to recontact the videomixer, and 
>>> a restart
>>> is needed. I'll take care of this in the next release.
>>>
>>>
>>>  
>>>       
>>>> - the videomixer does not close all UDP sockets when a conference is 
>>>> terminated.
>>>>     
>>>>         
>>> Same as above, not all resources, including connections and RTP 
>>> channels, are
>>> appropriately freed when the mixer shutdowns. I'll add this in the next
>>> release.
>>>
>>>
>>>  
>>>       
>>>> Finally I have some questions about the architecture of the 
>>>> videomixer. If I understand it correctly, the Meetme application 
>>>> receives the video frames from Asterisk core (which received it from 
>>>> chan_sip) and forwards it to the videomixer via UDP. Videomixer 
>>>> receives the video, mixes it, and sends the streams back to Meetme. 
>>>> Meetme sends video to the SIP clients.
>>>>
>>>> Why is ortp needed? Is the communication between videomixer and 
>>>> MeetMe based on RTP and Meetme acts as bridge for the RTP video packets?
>>>>     
>>>>         
>>> Exactly, Asterisk acts as an RTP bridge for media streams. Even if the 
>>> ideal
>>> case would be a direct media flow between users and the mixer, having 
>>> Asterisk
>>> in the video path is unavoidable at the moment. In fact, such a 
>>> feature would
>>> require appropriate renegotiation, which:
>>>
>>>       1. can't be done in a transparent way for whatever channel 
>>> driver (you can
>>> only bridge channels);
>>>       2. can't be done hacking a single channel driver as chan_sip 
>>> either,
>>> considering how chan_sip is conceived at the moment; in fact, 
>>> redirecting the
>>> video flow would require a media-specific c-line for video, a 
>>> granularity that
>>> is not possible in the current chan_sip because of the fact that the SDP
>>> processing still is not media-specific at all; a CANREINVITE would not 
>>> be the
>>> solution since it would involve all the media in the SDP (so audio too).
>>>
>>>
>>>  
>>>       
>>>> regards
>>>> klaus
>>>>
>>>>     
>>>>         
>>> Thanks a lot for your precious feedback, it's much appreciated!
>>> If you have any other question and/or advices/suggestions/criticisms 
>>> about this
>>> work, I'll be glad to hear them.
>>>
>>> Regards,
>>> Lorenzo
>>>
>>>   
>>>       
>> _______________________________________________
>> --Bandwidth and Colocation provided by Easynews.com --
>>
>> asterisk-video mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-video
>>     
>
>
>   

-- 
My wife's sister is in California.  
I should buy her a Videophone2008!

Truly, The Next Best Thing to Being There!
--

WorldWideVideoPhones.com
856.380.0894



-------------- next part --------------
A non-text attachment was scrubbed...
Name: david.cantera.vcf
Type: text/x-vcard
Size: 302 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-video/attachments/20070621/1a5490fb/attachment.vcf 


More information about the asterisk-video mailing list