Re: [codec] [payload] Frames to Packets in draft-ietf-codec-opus-07?

["Benjamin M. Schwartz" <[e-mail]>]

On 07/25/2011 10:23 AM, Christian Hoene wrote:
> I was wondering why the draft-ietf-codec-opus-07 draft has feature to
> concatenate multiple codec frames to packets. At the same time,
> draft-spittka-payload-rtp-opus-00 does not support to place multiple codec
> entities in on RTP packet.

I think we are in agreement that for many packet transports, a single
frame per packet (max duration of 20~ms for general audio, minimum of
2.5ms or 400 pps) would be inappropriate, and so a concatenation scheme is
required.  The question is then: where should the concatenation scheme be
specified?

The motivation for specifying concatenation inside the codec is to promote
interoperability and adoption by reducing the total amount of engineering
work required to implement Opus.  This happens in two ways:

1. Avoiding duplicative software work

Given the structure of existing networked audio software, I expect that
software using Opus will typically rely on a pre-existing Opus library,
and there will be only a small number of widely used Opus implementations.
 However, there will likely be many implementations of the Opus-RTP
specification, due to engineering integration requirements.  As such, we
can reduce implementation effort by minimizing the complexity of the RTP
specification.

2. Avoiding duplicative specification work

Opus will be distributed over many transports other than RTP, and a
concatenation scheme may be desirable in each case.  Specifying
concatenation inside the codec avoids the need to specify a new
concatenation scheme for every transport.  Having a single concatenation
scheme should therefore accelerate adoption, minimize confusion when
moving packets between transports, and minimize the amount of software
required to make Opus work.

Personally, I've found H.264 to be an example of how specifying framing
outside the codec can create problems. H.264's packet/framing schemes (the
"network abstraction layer", "access units", bytestream alignment, etc.)
are specified outside the codec, so that they must be handled by the
stream processing layer.  Correctly distinguishing and converting between
the various possibilities is so confusing that, until the latest release
last month, gstreamer's H.264 parser could not correctly depayload H.264
from the popular AVCHD format.