[Linphone-developers] Possible bug in mediastreamer when switching between different video codecs

[Jean-Paul Iribarren]

Hi Linphone wizards,

First, thank you all for this great piece of software. And now, on for
the bad news : I think I have found a nasty bug which triggers when
Linphone switches between two different video modes. I noticed this
issue with Linphone 3.6.1 (Win32), with msx264 plugin 1.4.3, used on a
Windows XP Pro/SP3 workstation, but I think it could happen with Linux
versions as well.

The problem showed up during the following video call scenario: Linphone
is registered on a FreeSWITCH server as extension 1000. This extension
is a member of a call center, which can be called by dialing 7002. When
FreeSWITCH receives an incoming call for (virtual) extension 7002, it
rings all members of the call center (including 1000), and it plays
music on hold to the call issuer. When Linphone goes off-hook,
FreeSWITCH bridges the leg of the incoming call with the leg of
extension 1000.

Video support is configured as follow:

- preferred video codecs on FreeSWITCH: H.263,H.264 (in this order)
- caller's video codec: H.264
- Linphone video codecs: H.264, H.263

Therefore, everybody has H.264 in common.

In this situation, at incoming call time, FreeSWITCH and Linphone
initially negociate H.263 video. Linphone logs the following messages
regarding its video filters stack:

    message: ms_filter_link: MSDsCap:021AB0D8,0-->MSPixConv:021A4C90,0
    message: ms_filter_link: MSPixConv:021A4C90,0-->MSSizeConv:0219BB38,0
    message: ms_filter_link: MSSizeConv:0219BB38,0-->MSTee:021CE170,0
    message: ms_filter_link: MSTee:021CE170,0-->MSH263Enc:021A13B0,0
    message: ms_filter_link: MSH263Enc:021A13B0,0-->MSRtpSend:0184BD90,0

    message: ms_filter_link: MSRtpRecv:02169FB0,0-->MSH263OldDec:02169FE8,0
    message: ms_filter_link: MSH263OldDec:02169FE8,0-->MSTee:021EF310,0
    message: ms_filter_link: MSTee:021EF310,1-->MSJpegWriter:021EF280,0
    message: ms_filter_link: MSTee:021EF310,0-->MSDrawDibDisplay:021A86C8,0
    message: ms_filter_link: MSTee:021CE170,1-->MSDrawDibDisplay:021A86C8,1

Later, when connecting legs, Linphone notices that it must switch from
H.263 to H.264 to exchange data with the remote end, and it logs the
following messages (and nothing else) regarding stack reconfiguration:

    message: ms_filter_unlink:
MSRtpRecv:02169FB0,0-->MSH263OldDec:02169FE8,0
    message: ms_filter_unlink: MSH263OldDec:02169FE8,0-->MSTee:021EF310,0
    message: ms_filter_link: MSRtpRecv:02169FB0,0-->MSH264Dec:02B1FC00,0
    message: ms_filter_link: MSH264Dec:02B1FC00,0-->MSTee:021EF310,0

After these steps, Linphone receives and displays correctly the H.264
video flow sent by the caller, but it keeps on sending H.263 video
*while pretending it is H.264 at RTP level*. Therefore, the remote end
is unable to decode and display the video flow sent by Linphone.

I noticed this problem when using Linphone with FreeSWITCH, but I
suppose it could happen in any situation where Linphone (actually,
mediastreamer) must switch from one video mode to another at answer time
(what about audio? Perhaps the same issue exists).

Many thanks in advance for having a look.
-- 
JPI