Re: [Ekiga-devel-list] [OpenH323]Some points on the EKIGA/OPAL video plugin

[Craig Southeren <craigs postincrement com>]

Comments inline

On Wed, 25 Oct 2006 21:58:32 +0200 (CEST)
Matthias Schneider <ma30002000 yahoo de> wrote:

> Hi all, 
> 
> in the process of developing a video plugin for ekiga/opal I noticed some things that I would like
> to clarify. Everything mentioned here refers to the latest HEAD version of OPAL, EKIGA nd PWLIB.I
> am posting this to both openh323/opal and ekiga lists since some topics do concern both software
> packages..
> 
> OPAL issue:
> 
> - in patch.cxx OpalMediaPatch::Main() we do a sleep (5) after each packet received
>   5ms sleeping is much too long and has lead to buffer overruns in the UDP input que in my case
> (e.g. if a frame is transmitted as 4 packets at 25fps, and we need 20 ms waiting after the
> received packet, leaving only another 20 ms per frame to decode and display it - not enough in my
> case) Right now my workaround is to wait 5 ms only after every frame since I have not yet
> understood the motivation for this sleep - the select that is called in order to collect the
> packets should e blocking anyway, so we dont need any sleep? Or does this depend on the platform?
> Possibly this problem doesnt appear on windows - there is an #if !defined (WIN32) in the code.
> Also I do not understand which other thread should be allowed to take the mutex...

The 5ms sleep was inserted to prevent the codec thread from consuming
all of the available CPU time. This commonly occurs on Linux with it's
"opportunistic" scheduling, but can also occur on Windows too.

> 
> EKIGA bug:
> 
>   - EKIGA does not complete a remotely initiated termination of a call (see attached file
> terminate.txt) - happens with different endpoints. If video is activated, outbound video
> transmission does not even stop. If the connection is terminated by ekiga everything works like
> expected.
> 
> Plugin uncertainties:
> 
> - dynamic RTP
>   If I understand correctly, EKIGA/OPAL should support dynamic RTP payload types (like in the
> speex plugin) for video as well.

Correct

>     - Is it correct interpretation of RFC 4566 (please advise if there is an RFC more specific on
> dynamic RTP PTs) that the rtpmap attribute specifies the PT on which it will be received and that
> it can be asymmetric (e.g. A sending with PT 96 while receiving the same codec on 99 because A
> sent an SDP line "a=rtpmap:99 X/90000" and B "a=rtpmap:96 X/90000"?

This sounds correct, and OPAL should handle this case.

>   - How do I handle dynamic RTP types in a video plugin? As I understand there are two options -
> shared RTP code (e.g. speex) and separately coded RTP (e.g. h263ffmpeg.cxx). If I understand
> correctly I have to register a dynamic PT codec plugin with the RTPTypeDynamic flag. - With which
> PT do I register my plugin? How do I know with which RTP PT to tag the outgoing frames? Or is it
> mandatory to use the shared RTP code in this case? How do I put in the correct timecode and maker
> in that case? 

Your understanding is not quite accurate.

The two modes for RTP are either explicit RTP payload code (used for
codecs that have defined payload types such as G.711 or H.261) and
dynamic payload codes (used for everything else)

Where there are many codecs with the same IANA name and clock rate (such
as Speex narrow band audio), OPAL will automatically use the same
payload code for all of them in order to avoid the needless consumption
of the limited RTP payload code space. This is not something you need to
worry about as it happens automatically and should not affect anything
else

> Also, if I add the RTPTypeDynamic flag instead of RTPTypeExplicit, the
> codec does no longer appear in the EKIGA codec list...

Have you tried the opalcodecinfo program that is supplied with OPAL? It
lists the available codecs as reported by the underlying OPAL system -
this would help determine if the problem is in OPAL or Ekiga.
 
> - fmtp handling
>   How is the a=fmtp line in sip/sdp handled? I noticed that it is possible to hand an fmtp line
> from the encoder side to the SDP handler like in speex. However this happens BEFORE options like
> width and height of frame are set up, making it impossible to include anything based on that in
> the fmtp line, which is sometimes necessary. Also I am wondering how the received a=fmtp line is
> passed to the decoder.

fmtp handling is not yet complete

> General Questions:
>   - cerr and PTRACEs commented out in h323ffmpeg.cxx
>   All log output in h323ffmpeg.cxx is commented out. What would be the correct way for outputting
> log information in a video plugin without introducing unneccessary dependencies?

I'm not sure. It's not easy to provide a mechanism for outputting
debugging from a plugin that is loaded (perhaps) by a program that has
no console. Under Windows, any console output from a GUI program is
silently discarded - I'm not sure about Linux.

..deleted

   Craig


-----------------------------------------------------------------------
 Craig Southeren          Post Increment ? VoIP Consulting and Software
 craigs postincrement com au                   www.postincrement.com.au

 Phone:  +61 243654666      ICQ: #86852844
 Fax:    +61 243656905      MSN: craig_southeren hotmail com
 Mobile: +61 417231046      Jabber: craigs jabber org

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting