linphone-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] Linphone 2.99.1 Build Issue


From: Simon Morlat
Subject: Re: [Linphone-developers] Linphone 2.99.1 Build Issue
Date: Sun, 31 Aug 2008 15:40:25 +0200
User-agent: KMail/1.9.9

Le Thursday 28 August 2008 21:23:40 Conrad Beckert, vous avez écrit :
> Hi Simon,
>
> hey cool, it worked!!!! That's great.
>
> I connected immediately to my Asterisk server to do some tests.
>
> First of all, I'm impressed with the larger video output. It looks nice to
> get away with the stamp size image.
>
> I the tried to establish a connection between the Windows Version 2.99.2
> and my newly installed Linux linphone. I run into an old phenomenon which
> bugged me for some time: the no video (green) at the called side (sound
> ok).
The video might take some time to appear if the very first packets (that 
contain the video key frame) are lost. Normally after a tens of seconds it 
should be up.
>
>
> I Videocall
> =======
> I succeeded as I deactivated the h263 codec on the linux side (not the
> h263-1998one). This issue is reproducable. (and a known pain from earlier
> versions) The Windows Version doen't have a plain h263 codec so I couldn't
> test.

The H263 codec is not fully tested. I never used it.

>
> On the Asterisk log, I get recurring messages like this:
> [Aug 28 02:53:56] NOTICE[25213]: rtp.c:1283 ast_rtp_read: Unknown RTP codec
> 72 received from '85.178.118.193' [Aug 28 02:54:00] NOTICE[25213]:
> rtp.c:1283 ast_rtp_read: Unknown RTP codec 72 received from
> '85.178.118.193' [Aug 28 02:54:05] NOTICE[25213]: rtp.c:1283 ast_rtp_read:
> Unknown RTP codec 72 received from '85.178.118.193' [Aug 28 02:54:09]
> NOTICE[25213]: rtp.c:1283 ast_rtp_read: Unknown RTP codec 72 received from
> '85.178.118.193' [Aug 28 02:54:14] NOTICE[25213]: rtp.c:1283 ast_rtp_read:
> Unknown RTP codec 72 received from '85.178.118.193'
>
> sometimes I had this:
> [Aug 27 22:50:30] WARNING[24417]: rtp.c:891 ast_rtcp_read: RTCP Read too
> short [Aug 27 22:50:30] WARNING[24417]: rtp.c:891 ast_rtcp_read: RTCP Read
> too short [Aug 27 22:50:35] WARNING[24417]: rtp.c:891 ast_rtcp_read: RTCP
> Read too short [Aug 27 22:50:50] WARNING[24417]: rtp.c:891 ast_rtcp_read:
> RTCP Read too short [Aug 27 22:51:05] WARNING[24417]: rtp.c:891
> ast_rtcp_read: RTCP Read too short

Only asterisk knows what that means. The RTCP packets sent by linphone are 
perfectly analysed by wireshark, I don't think there is a linphone bug behind 
that.
By experience I'm not very confident with asterisk. If you need a proxy with 
relay feature, try the openser proxy running at http://sip.antisip.com. It 
works very well, I always use it, and make things working perfectly even with 
clients behind firewalls.
Of course you can setup your own openser if you wish !

>
>
>
> The linux version constantly prints into its terminal while a videocall is
> active: [h263 @ 0xb76159a8]warning, clipping 1 dct coefficient to -127 ..
> 127 [h263 @ 0xb76159a8]warning, clipping 1 dct coefficient to -127 .. 127
> ...
> and then
> [h263 @ 0xb76159a8]vbv buffer overflow
Simply ignore them, it is just ffmpeg telling us its life...
It does not have any effect on the video, these are normal.
>
>
>
> The image quality from the Linux side is somewhat poor. (blocks, artefacts
> etc.) The Windows side sends better images (aarrggh?? Why??)  Bandwith is
> set to 512/192 (which I don't have since I use up my bandwith by sending
> the rtp data back and forth to my asterisk server at a different location)
> The difference in quality is striking.
You mean that the video displayed on windows is degraded true ?
Have you tried a lesser bitrate (128 kbit/s) ? I wonder whether the windows 
socket buffer can be too short and then discard some video packets.
Please also try lastest tarball and setup.exe, I've improved things about 
bandwidth management.
If you think quality is equal with a lesser bitrate, just tell me, I'll fix 
the windows release to enlarge the socket buffer.

>
>
> II Audio
> =====
> Anyway. I managed to get a connection using the gsm audio codecs. The speex
> one cause crackling noise. (that can be an issue with my notebook though)
>
> There is one phenomenon I had in production - and managed to get in my
> tests as well (not reproducable unfortunately): Sound is OK, one can hear
> background noise from the other side crystal clear - but once the speaker
> starts to talk the volume goes zero (and hence one cannot understand what
> the other person says)
Seems to an automatic gain control running on one side (the windows one ?).
Try to check whether it can be disabled on the windows audio properties.

>
>
> III x264
> =====
> I then tried to compile the x264 codec. That succeeds but I cannot see it
> in the list of codecs in linphone. I then deleted everything that looks
> like 264 - with the result to kill ffmpeg. (linphone wouldn't start
> anymore) Anyway. What am I supposed to to to get x264 to work? (parameters
> etc)
Check that you always have the lastest linphone tarball together with the 
lastest msx264 tarball. msx264 cannot work with an older linphone.
(I 'll take care of binary incompatibilities  later!)
Compile _everything_ (ffmpeg, msx264, linphone) with --enable-shared (this is 
the default except for ffmpeg and x264). Statically linked binaries cannot 
load plugins.
Use the x264 snapshot available from my download page (next to the plugin). It 
is modified to reach better interroperability.
Then take care that linphone and msx264 got installed in the same prefix 
(eg /usr/local). The plugin is normally installed 
in /usr/local/lib/mediastreamer/plugins/ .
As you see source compiling of linphone becomes very tricky...

Simon





reply via email to

[Prev in Thread] Current Thread [Next in Thread]