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 _______________________________________________ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list