It's in stream info directly. It can vary during the call and doesn't need to be negociated, each packet contains the info of the clock rate. Using the decoder higher level api, you just have to wish a clock rate you'd like to use and the codec implementation will take in charge to resample if necessary. On the other way when you encode you tell the codec that your input is for example 16kHz, and it will take in charge to resample if necessary. There is also a way to specify in SDP fmtp params the actually used clock rate of your decoder, so that sender (encoder) will not use higher than this value to not do unefficient use of the network. But that's a non mandatory parameter and the decoder will still work even if this is not taken into account by remote side. There is the same mechanism for PLC (FEC), you tell in SDP that your decoder will not take into account packet loss and so will not use FEC info, so that remote side encoder knows that it's not necessary to send FEC infos and so will save bandwidth usage. As far as I understood it's a little bit like the bandwidth / target bandwidth mechanism for other codecs that have variable bandwidth, but here it also impacts clock rate. Regards, R?gis 2012/5/23 Benny Prijono <bennylp at teluu.com> > Hi R?gis, > > How does the offerer know which clock rate is used/negotiated? Sorry I > haven't searched any docs yet. > > Best regards, > Benny > > > On Thu, May 17, 2012 at 9:24 PM, R?gis Montoya <r3gis.3r at gmail.com> wrote: > >> 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> <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 listpjsip at lists.pjsip.orghttp://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing listpjsip at lists.pjsip.orghttp://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 >> >> > > _______________________________________________ > 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/20120523/5c61956c/attachment.html>
