Hi Nanang, Thanks for the point. Actually I did a mistake integrating opus codec. Thanks to feedback from nice guys working on opus, I got that the SDP to announce for opus is always opus/48000 . The codec is able to manage clockrate changes and re-sampling by itself. So the problem with dynamic PT is very reduced with that :) (from 5 to 1 :) ). The problem I've now is that the design of pjmedia seems not made to manage this kind of case. I'd like to configure the codec with pjsua_codec_set_param <http://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB__MEDIA.htm#gab5a78d3b880d47636abfa9c2077eabd0> to set the target clock rate from the application in order to avoid useless sampling from both pjsip. For example, I'd like to have device open @16kHz, opus open @16kHz and leave opus resample and adapt to bandwidth capacity. In pjmedia, if I keep things the way it's done for other codecs, I'll have device open @16kHz, pjmedia resample, opus open @48kHz (and more likely opus will resample again). I thought that pjsua_codec_set_param was the good solution to do that. I'm able to take that into account in opus glue to open opus at correct clock rate. The problem is that stream seems to not take that into account. The best solution I found was to modify pjmedia to make force stream to take into account codecs params. You can find the patch here : http://code.google.com/p/csipsimple/source/browse/trunk/CSipSimple/jni/pjsip/patches/007reapply_codec_clock_rate.diff Even if it doesn't break anything -- since all codecs implementations already correctly set their clock_rate to good value -- I think it's not the correct way to do that, since pjmedia_codec_param <http://www.pjsip.org/pjmedia/docs/html/structpjmedia__codec__param.htm> has "clock rate" setting, I guess this case is managed by pjmedia, but I was not able to get things working. Also, I've another question, is there a way in codec implementation to "validate/modify" settings entered by application layer? For example with opus there is support of vad and plc. As far as I understood, the sdp should announce this support to remote party so that remote party include necessary information in case of PLC support. So if I disable plc in codec settings, I should also add an extra fmtp_param for decoder to tell that it will not use FEC info and it should not be sent in packet. For clockrate it's the same, the sdp can announce remote part it will only treat 16kHz as max clock rate, so remote side can decide to optimize what it sends. This announce is also a fmtp_param for decoder. I could do that from application, but would be great to be able to do that from the codec implementation automatically. It could be interesting for clock_rate too in order to ensure the clock rate is valid regarding the PT value. Regards, R?gis On 16/05/2012 03:24, Nanang Izzuddin wrote: > Hi R?gis, > > Right, actually there is already an old ticket for this: > https://trac.pjsip.org/repos/ticket/1297. However it will be done > after 2.0 (can't really promise when). > > Thanks for the feedback. > > BR, > nanang > > > On Sun, May 13, 2012 at 1:45 AM, R?gis Montoya <r3gis.3r at gmail.com> wrote: >> Hi all, >> >> Just to inform that a new codec implementation is available in CSipSimple >> project. >> It's for OPUS (http://opus-codec.org) codec (I've also updated SILK codec >> glue). >> >> As usually with codecs made in CSipSimple it doesn't include makefile or >> toolchain for other platform, but the codec implementation (one file) itself >> is compatible with all platforms. >> So if you need to use it for other platforms it should not be too hard (all >> the more so as libopus has standard gnu make files). >> >> Source code : >> http://code.google.com/p/csipsimple/source/browse/trunk/CSipSimple/jni/opus/pj_sources/pj_opus.c >> >> I've also a question/remark about new codecs integration in pjsip. >> In CSipSimple I'm now able to load codecs dynamically from plugin >> applications. Thanks to the great design of codec api it's pretty easy to >> load dynamically codecs from dyn libs. >> >> However, each time I add a new codec, I need to modify the known payload >> types of the pjsip stack and ensure it's not more than 127. >> That's very annoying for 2 big reasons : >> * I will reach the limit very soon... in addition to all codecs supported >> by pjsip, I've added CODEC2, SILK, ISAC and OPUS. If you multiply by the >> number of frequency supported... ;) >> Don't be confused, my point is not that I may potentially reach 127 in my >> SDP. Nobody will use all codecs at same time. The point is that even if I >> don't load or leave deactivated some codecs, the dynamic pt in SDP is >> static. >> * The second reason is that it's impossible to enrich the application only >> adding new plugins. Each time I want to create a new plugin I should update >> the pjsip stack *ONLY* to add new dynamic PT ! >> Well I could add new values but would lead to potential conflict. >> >> So, I'm wondering if it would not be possible to make independent dynamic >> payload types (as announced by endpoint) and codec. >> Maybe simply adding 0 in codec implementation and in endpoint when a 0 is >> encountered, consider it should manage allocation of pt dynamically based on >> something it manages itself. For example with a map between dynamic pt >> created and codecs of codec manager (fully qualified name). >> BTW, it will be possible to manage in the method allocating new pt numbers >> to reserve some dynamic types (for example the one for telephony event). >> >> What do you think? Does that makes sense and could be added as a new ticket? >> Or is there technical reason why it shouldn't be done this way? >> >> Regards, >> R?gis >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120517/d4f3c98e/attachment.html>
