On Sun, 26 Nov 2006 12:14:29 +0100 Julien Puydt <[EMAIL PROTECTED]> wrote:
..deleted > Here is how gstreamer does, as far as I know : they get the data and > feed it to their codecs, which return something which measures their > confidente it is "correct data" for them. > > So by elimination, they get the right codec, which can then be confirmed > and better tuned afterwards. This sounds like it could require a lot of resources. Imagine a mobile device that has only limited CPU and supports a wide variety of audio and video codecs. Pushing every received RTP packet through every offered codec in order to find one that seems to works would require a lot of extra code to be written, and would require a lot of extra CPU. And it still doesn't address the other issues I described. I think there some other issue at work here. Can someone provide me with a trace log of a call that has the "three second delay"? I'm thinking that perhaps the remote end is sending a 183 with media session information, but for some reason OPAL is not processing the media until the 200 OK is received. But until I get a level 4 trace, I won't know for sure... Craig ----------------------------------------------------------------------- Craig Southeren Post Increment VoIP Consulting and Software [EMAIL PROTECTED] www.postincrement.com.au Phone: +61 243654666 ICQ: #86852844 Fax: +61 243656905 MSN: [EMAIL PROTECTED] Mobile: +61 417231046 Jabber: [EMAIL PROTECTED] "It takes a man to suffer ignorance and smile. Be yourself, no matter what they say." Sting _______________________________________________ ekiga-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/ekiga-list
