Regis,
I think in my case I don't have to many choices, so I decided to
follow dirty way, by accessing frames from jbuf.
There is a function "static pj_status_t get_frame( pjmedia_port *port,
pjmedia_frame *frame)" in stream.c. It has a loop which iterates all
available frames and passes them to decoder in case frame is good, or
to recover in case frame is broken. What I think, is to pass next two
frames to SILK pjmedia codec instance, before sending broken frame to
recover function. So SILK glue will have next two frames after
receiving broken frame in "recover" function.
The problem is that loop inside "get_frame" function iterates only
once, so there is no ability to ask for next n+1 and n+2 frames ??we
have only one frame here. Maybe its configurable somewhere?
samples_required = stream->port.info.samples_per_frame;
samples_per_frame = stream->codec_param.info.frm_ptime *
stream->codec_param.info.clock_rate *
stream->codec_param.info.channel_cnt /
1000;
...
for (samples_count=0; samples_count < samples_required;
samples_count += samples_per_frame)
{
...
}
samples_required and samples_per_frame are always equal, means I don't
have future frames here.
Do you know any idea where I can search for future frames?
Regards,
Oleg
On Wed, May 30, 2012 at 11:13 AM, R?gis Montoya <r3gis.3r at gmail.com> wrote:
> Well, after re-reading docs, by default INBandFEC should be assumed to be 1
> by the encoder :). I'll fix that too.
>
>
> On 30/05/2012 10:41, Oleg Lutsenko wrote:
>
> Regis,
>
> The problem is that I need to work with SILK, so I can not move to Opus. Do
> you have any idea how to get access to?the frames from jbframes?
>
> Regarding note 1, I think that your implemenatation doesn't need any
> changes, because it looks like it already?notifies remote side that you do
> not have support of FEC:
>
> SKP_int32 INBandFEC_enabled =?0 ...
> ...
> ?silk->enc.useInBandFEC? ? ? ? ??= INBandFEC_enabled;
>
> Regards,
> Oleg Lutsenko
>
> On Friday, May 25, 2012 at 9:20 PM, R?gis Montoya wrote:
>
> 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
>
>
>
>
> _______________________________________________
> 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
>
