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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120523/bc5cd79c/attachment-0001.html>
