[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