[Ekiga-devel-list] Dynamic RTP PT for video

[Matthias Schneider <ma30002000 yahoo de>]

Hi all, 

some days ago I have posted some issues about using dynamic RTP Payload Codes for video codecs
which I would like to summarize and clarify now (there was a misunderstanding about the
RTPTypeShared attribute from my part)

- Ekiga and video codecs with dynamic RTP payload:
  As mentioned in my previous mail ekiga only puts video codecs in its own codec-list that are
available for H.323 and SIP and share the same payload type code (in OPAL everthing seems fine
with the assigned payload type codes). However if the payload type code is dyanamic, the H.323 and
SIP instances get assigned different payload type codes. The code responsible is:

  manager.cpp lines 286- :

      if (sip_list [i].GetPayloadType () == h323_list [j].GetPayloadType ()
          && sip_list [i].GetBandwidth () == h323_list [j].GetBandwidth ()) {

        full_list += sip_list [i];
        full_list += h323_list [j];
      }
  Now the question is what other property could we take to make this comparison? What about the
user data field?

- OPAL plugins and dynamic video codecs
  If I understand correctly, the plugin interface to audio codecs differ from the interface to
video codecs in one way:
  Audio codecs only pass the PAYLOAD field in the RTP frame to OPAL - Video codecs however do pass
the ENTIRE RTP frame to OPAL (i.e. including Marker, timecode, payload type,...) 
  The problem when dealing with video plugins is now that the plugin is responsible for setting
the payload type code field in the RTP frame to be transmitted. However the plugin is unaware of
the PT code that the communication peer has advertised. 
  My proposal is now to pass the assigned payload type code to the plugin via an options field. I
suppose this would have to be done in mediafmt.{h|cxx}. I have been working on this all the day of
today, however I face the problem that I apparently cannot catch the correct OpalMediaFormat
instance to pass the PT code to the plugin. 

  My idea was to put something like 

  const char * const OpalMediaFormat::RTPPayloadTypeOption = "RTP Payload Type";
  AddOption(new OpalMediaOptionInteger(RTPPayloadTypeOption,      false,
OpalMediaOption::AlwaysMerge, PAYLOADTYPE));

  into mediafmt.cxx
  It would be really nice if someone who knows the code better than I do could help me in some
way...


- OPAL and 5ms problem
  In patch.cxx OpalMediaPatch::Main() we do a sleep (5) after each packet received which leads to
a input queue overflow when receiving high-bitrate traffic
  The corresponding code looks like this:
    if(!source.IsOpen() ||
        sinks.GetSize() == 0 ||
       !source.ReadPacket(sourceFrame))
    {
      inUse.Signal();
      break;
    }
    .....
    if (!isSynchronous || !sourceFrame.GetPayloadSize())
      Sleep(5); // Don't starve the CPU
#if !defined(WIN32)
    else
      Sleep(5); // Permit to another thread to take the mutex
#endif
    }
    First what I do not understand why do we ALWAYS sleep(5) on non-windows systems. Second, if I
understand correctly the ReadPacket somewhere calls a select() in order to collect incoming
packets which to my understanding is blocking on linux systems. Now since the select() should
remain blocked until a packets arrives, I do not see the need for an additional sleep. Please
correct me if there is some wrong understanding from my part.

Thank you in advance,
Matthias




	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de