[codec] Ogg Opus zero-length frames

Mark Harris <mark.hsj@gmail.com> Thu, 15 August 2013 00:37 UTC

Return-Path: <markh.sj@gmail.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 E481D21E80FA for <codec@ietfa.amsl.com>; Wed, 14 Aug 2013 17:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 9O41+ToucO-b for <codec@ietfa.amsl.com>; Wed, 14 Aug 2013 17:37:11 -0700 (PDT)
Received: from mail-we0-x244.google.com (mail-we0-x244.google.com [IPv6:2a00:1450:400c:c03::244]) by ietfa.amsl.com (Postfix) with ESMTP id B29C221E80F9 for <codec@ietf.org>; Wed, 14 Aug 2013 17:37:10 -0700 (PDT)
Received: by mail-we0-f196.google.com with SMTP id p61so38821wes.3 for <codec@ietf.org>; Wed, 14 Aug 2013 17:37:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=KhIpcnM5mH1yCwEfmfakDQEepjJoxIJGNCtDBtRXm4s=; b=Cs+qkBAjioWrNcIS92tmazlU/gX0rEwKy3mfzRWp91ZcsQpea9nUUFSngTQMgkwvxz GohojYoxdBQA7BLwjvq5qAEyjkROLHTc6YkJTr/Tm+hUpgZidnjD+On2p4LBYq2T+A3X IwVweSHab00mHvs/j6v+py77Pksn1hv4glroRJmMmC+tdToLzUOgq3ck1wQSOAdlBkr2 O+FYQJ66gbWevulRCZr3vDMVbSt8FdaBQhaonWeqFLa4EyzfkgHJP3NqaSmx6W1ynFbf mXCph7onPdiKfqMi9NnsYTbrwQ37yg6mKPZpv8uWmv3JiKGE13rwzoS1jz2GF8MzGMGW 2wmA==
MIME-Version: 1.0
X-Received: by 10.180.98.3 with SMTP id ee3mr145777wib.48.1376527029870; Wed, 14 Aug 2013 17:37:09 -0700 (PDT)
Sender: markh.sj@gmail.com
Received: by 10.194.76.234 with HTTP; Wed, 14 Aug 2013 17:37:09 -0700 (PDT)
Date: Wed, 14 Aug 2013 17:37:09 -0700
X-Google-Sender-Auth: N-HS9y5-7y9ykl9ZECtumCrjovU
Message-ID: <CAMdZqKEDk4rJeEWr-0-oxHQDiy+Lk5QQei9-b+yrXLSRYs8GhQ@mail.gmail.com>
From: Mark Harris <mark.hsj@gmail.com>
To: codec@ietf.org
Content-Type: text/plain; charset="UTF-8"
Subject: [codec] Ogg Opus zero-length frames
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, 15 Aug 2013 00:41:46 -0000

According to draft-ietf-codec-oggopus-01 section 4, Opus frames
with length 0 can be used to fill in gaps when writing Opus to Ogg,
since no gaps are allowed.  That makes sense, and is useful for
representing frames that were lost, corrupted, or not transmitted
due to DTX.  However those frames need to go in packets, which
require a TOC.  That means that in order to represent packets that
are not available, the muxer must synthesize a TOC.

It would be nice to have guidelines for encoding these gaps in the
Ogg Opus draft, including:

  * Clarification that zero-length frames should be written, with
    a synthesized TOC if necessary, in the case of missing frames
    (e.g. due to packet loss or corruption).  Currently section 4
    only mentions these frames in the context of an encoder with
    DTX enabled.

  * Clarification as to whether the LP/Hybrid/MDCT mode and stereo
    bit matter for zero-length frames, and if so then a recommended
    method of choosing these when it is necessary to synthesize a
    TOC.  This may be influenced by the duration of the gap, since
    not all valid gap durations are possible to encode in LP mode.

  * Clarification as to whether the number and duration of the
    individual frames matter, as long as the total duration is
    correct, or a recommended method of choosing frame durations.
    For example it takes fewer bytes to encode a 95ms gap as 19 5ms
    frames (using a single code 3 CBR packet), but if the previous
    packet was LP mode it may be better to use multiple packets
    with longer frames in order to remain in LP mode as long as
    possible.  There may also be a benefit to keeping the previous
    frame size as long as possible.

  * Clarification as to whether zero-length frames may be used in
    code 0 or code 1 packets, since RFC 6716 section 3.2.1 is
    referenced which only mentions their use in code 2 and code 3
    packets.

  * Clarification as to whether it is acceptable to combine
    synthesized zero-length frames with other longer frames in the
    same code 2 or code 3 packet, when the TOC matches.

  * Recommended method of recording gaps that are not a multiple of
    2.5ms.

--