Re: [codec] Questions about FEC

Jean-Marc Valin <jmvalin@jmvalin.ca> Thu, 25 April 2013 02:59 UTC

Return-Path: <jmvalin@jmvalin.ca>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0119721F856D for <codec@ietfa.amsl.com>; Wed, 24 Apr 2013 19:59:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kSwK5xK2UI2 for <codec@ietfa.amsl.com>; Wed, 24 Apr 2013 19:59:17 -0700 (PDT)
Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by ietfa.amsl.com (Postfix) with ESMTP id D4D9521F84F6 for <codec@ietf.org>; Wed, 24 Apr 2013 19:59:17 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; CHARSET="US-ASCII"
Received: from idefix.jmvalin.ca ([96.21.20.94]) by VL-VM-MR003.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0MLS00HB6IYSP760@VL-VM-MR003.ip.videotron.ca> for codec@ietf.org; Wed, 24 Apr 2013 22:59:16 -0400 (EDT)
Message-id: <51789BFD.9020901@jmvalin.ca>
Date: Wed, 24 Apr 2013 22:59:09 -0400
From: Jean-Marc Valin <jmvalin@jmvalin.ca>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
To: Alfons Martin <alfons.martin@symonics.com>
References: <516E8335.6080800@symonics.com>
In-reply-to: <516E8335.6080800@symonics.com>
Cc: codec@ietf.org, Patrick.Schreiner@symonics.com
Subject: Re: [codec] Questions about FEC
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Apr 2013 02:59:22 -0000

Hi,

I just checked in this fix in master:
https://git.xiph.org/?p=opus.git;a=commitdiff;h=1bf32bb;hp=f77410d
Let me know if you're still having issues.

Cheers,

	Jean-Marc

On 13-04-17 07:10 AM, Alfons Martin wrote:
> Sorry if you receive multiple copies.
> 
> Dear Jean-Marc,
> 
> I've got some problems with the FEC of Opus using the current stable
> release (1.02) from the repository.
> According to my understanding of FEC, the FEC information of the next
> packet is used to restore the former lost packet. But if I use the
> "packet_size of the lost packet" to invoke FEC for it, as recomended in
> the API documentation, the function opus_decode_native uses PLC because
> of line 748 in file opus_decoder.c:
> 
> "if (frame_size <= packet_frame_size || packet_mode == MODE_CELT_ONLY ||
> st->mode == MODE_CELT_ONLY){"
> 
> If I use "max_frame_size", like in the opus_demo invokation of
> opus_decode (file opus_demo.c, line 714), FEC is used for the last
> packet. But the recursive call inserts PLC for the other packets until
> "max_frame_size" is reached.
> This behaviour leads to a fragmented output-file.
> 
> If I use twice the "packet_size of the lost packet" to invoke
> opus_decode, PLC and FEC still seem to be called for only 1 lost packet
> and the outputfile is fragmented again.
> 
> So I changed file opus_decoder.c line 748
> 
> if (frame_size <= packet_frame_size || packet_mode == MODE_CELT_ONLY ||
> st->mode == MODE_CELT_ONLY)
> 
> to
> 
> if (frame_size < packet_frame_size || packet_mode == MODE_CELT_ONLY ||
> st->mode == MODE_CELT_ONLY)
> 
> But then
> 
> /* Otherwise, run the PLC on everything except the size for which we
> might have FEC */
> duration_copy = st->last_packet_duration;
> ret = opus_decode_native(st, NULL, 0, pcm, frame_size-packet_frame_size,
> 0, 0, NULL);
> 
> is called anyway, and Opus never reaches the FEC part.
> 
> I then changed the code to the following and it worked, but I'm not sure
> if I missed sth.:
> 
> opus_decoder.c:738-764
> 
>     if (decode_fec)
>    {
>       int duration_copy;
>       int ret;
>       /* If no FEC can be present, run the PLC (recursive call) */
>       if (frame_size < packet_frame_size || packet_mode ==
> MODE_CELT_ONLY || st->mode == MODE_CELT_ONLY){
>           return opus_decode_native(st, NULL, 0, pcm, frame_size, 0, 0,
> NULL);
>       }
>       if(frame_size == packet_frame_size && packet_mode !=
> MODE_CELT_ONLY && st->mode != MODE_CELT_ONLY){
>             /* Complete with FEC */
>             st->mode = packet_mode;
>             st->bandwidth = packet_bandwidth;
>             st->frame_size = packet_frame_size;
>             st->stream_channels = packet_stream_channels;
>             ret = opus_decode_frame(st, data, size[0],
> pcm+st->channels*(frame_size-packet_frame_size),
>                   packet_frame_size, 1);
>             if (ret<0)
>                return ret;
>       }else{
>           /* Otherwise, run the PLC on everything except the size for
> which we might have FEC */
>           duration_copy = st->last_packet_duration;
>           ret = opus_decode_native(st, NULL, 0, pcm,
> frame_size-packet_frame_size, 0, 0, NULL);
>           if (ret<0)
>           {
>              st->last_packet_duration = duration_copy;
>              return ret;
>           }
>       }
>       st->last_packet_duration = frame_size;
>       return frame_size;
>    }
> 
> What's your opinion on this?
> 
> Regards,
> Alfons
>