Ok, You're right, in fact what I use only enable the PLC feature of SILK that does extrapolation with SKP_Silk_PLC. That's why I observed that PLC is done. So the PLC feature is enabled, but you're right the FEC data is not used. I just had a closer look to opus source code and they slightly modified silk so that SILK is clever and does the FEC decode by itself managing buffers. Maybe we could get inspired of what is done in opus, but would mean adding extra complexity to SILK decode process by buffering things. Another solution would be to get the next frames from pjmedia jitter buffer; but AFAIK, there is no clean way to get the jb frames from a codec implementation, but I may be wrong. Side note 1 : with your remark in mind, I should fix my current implementation to announce remote side that I don't use FEC info for SILK codec. It will reduce packet size, since for now it's not implemented, not necessary to ask remote side to send FEC info :). Side note 2 : opus is definitely better and easier to use. If you have no constraint on the codec choice, you should maybe have a look on the opus project (it includes silk and use it for low bandwidth usage cases). And even if still not finalized it sounds really promising :). Regards, R?gis On 25/05/2012 17:06, Oleg Lutsenko wrote: > Regis, > > Correct, I am using your implementation, good job! Thank you! > > But as I understand from SILK documentation (SILK SDK API pdf document), you should call this function > > SKP_Silk_SDK_search_for_LBRR > > to retrive lost frame from next (n+1 and n+2) frames. And in your implementation you never call this function. > > Regards, > Oleg Lutsenko > > > On May 25, 2012, at 4:51 PM, R?gis Montoya wrote: > >> Oleg, >> >> I guess that you use my implementation (http://code.google.com/p/csipsimple/source/browse/trunk/CSipSimple/jni/silk/pj_sources/silk.c) of silk codec. >> >> As far as I understood from silk codec api, the storage of previous frames is done by SILK itself. So the implementation I did is already valid to use FEC feature of SILK. >> And for the few tests I did with SILK with my implementation it's already capable to retrieve lost frames. >> >> I could mistake however since I didn't spent a lot of time on the SILK implementation. But my guess are pretty confirmed by the Opus implementation I did later (opus is based on SILK + CELT). >> >> So normally, you have just nothing to do if you want to use FEC with pjsip + my codec implementation. >> >> Regards, >> R?gis >> >> >> Le 25 mai 2012 16:31, "Oleg Lutsenko" <oleg.lutsenko at googlemail.com> a ?crit : >> Hi guys, >> >> I am going to use nice FEC (Forward Error Correction) feature of SILK codec, to recover lost frames. To use this feature I need to have access to the next two frames after the lost one. This two frames include redundant information about previous frame, so, potentially, its possible to recover the lost frame. >> >> pjmedia_codec_op struct has recover function which I need to implement: >> >> pj_status_t(* pjmedia_codec_op::recover)(pjmedia_codec *codec, unsigned out_size, struct pjmedia_frame *output) >> >> The problem I have right now, is that I have no idea how to get any frame around the lost one. Is there any way how to get specific frame in a stream? >> >> Regards, >> Oleg Lutsenko >> _______________________________________________ >> 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 > > _______________________________________________ > 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
