Re: [codec] Questions about FEC

Jean-Marc Valin <jmvalin@mozilla.com> Wed, 17 April 2013 18:03 UTC

Return-Path: <jmvalin@mozilla.com>
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 0CEF721F85B0 for <codec@ietfa.amsl.com>; Wed, 17 Apr 2013 11:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level:
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1]
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 C5BtLpXgIIZy for <codec@ietfa.amsl.com>; Wed, 17 Apr 2013 11:03:23 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 454AD21E804B for <codec@ietf.org>; Wed, 17 Apr 2013 11:03:23 -0700 (PDT)
Received: from [192.168.1.109] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id C50C4F22C4; Wed, 17 Apr 2013 11:03:22 -0700 (PDT)
Message-ID: <516EE3E9.40802@mozilla.com>
Date: Wed, 17 Apr 2013 14:03:21 -0400
From: Jean-Marc Valin <jmvalin@mozilla.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Alfons Martin <alfons.martin@symonics.com>
References: <516E6F3D.2000203@symonics.com>
In-Reply-To: <516E6F3D.2000203@symonics.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Wed, 17 Apr 2013 18:03:24 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Thanks for reporting this. I'll need to have a closer look at that
code (which is relatively new and wasn't in the RFC) to see what's
going on.

	Jean-Marc

On 04/17/2013 05:45 AM, Alfons Martin wrote:
> 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
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRbuPpAAoJEJ6/8sItn9q9L3oH/jvFs5ECjE7hcGRB2L3h15P8
OwbpKduSC7JHq5GFBLDSgHvJ4VkkX+WvY+ZTlQR4TD+dFDjxrrC82Ab7xXKoHEi0
5H+GBN/mz3Usl7vow/wtAVX42Gk79dRDoKJYmWoFUWdttvCN7CPCUdnUqqctgiym
/KrjR48FzRLwXjjUVm1uO2IP9ITO4VGb4L/tZXyrCy8QlqgHoIXfDx2rBy15WB99
7fQPsNJfMw1bWEBrZ/1kaojH7PW0NyIcjVUDjryf15S9/RNPtSFA0trxbtbo3cZK
XCGDY/Q4dmZdqSI1DWGLCc2Lq4MMhJ8wuOh5bQjjc/+Cd9Bl3/a9jX7qTtKaJ78=
=4lMe
-----END PGP SIGNATURE-----