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

[Jonathan Lennox <[e-mail]>]

On Jul 25, 2011, at 1:56 PM, Benjamin M. Schwartz wrote:

> 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?

Does the Opus framing allow packets to be split and/or aggregated by a middlebox along frame boundaries, without requiring transcoding?  (The use case for splitting is to forward traffic to a box with a lower maxptime than the stream you're receiving, and the use case for aggregation is to reduce the RTP header overhead at the cost of some additional delay.)

I tried to read the Opus spec to answer my question, and I think I came up with the answer, but I wanted to confirm this with the Opus experts.

Based on my reading of the Opus spec, it looks like splitting should be possible, relatively trivially.  Aggregation, however, is only possible if the packets to be aggregated have the same value for the Opus TOC byte.

I get the impression that the TOC byte is expected to change only relatively infrequently in most encoding modes, in which case this would be fine -- there may be transient packets which couldn't be aggregated, resulting in occasional "short" packets, but most packets could be aggregated.  However, if an encoder might change its TOC frequently, this could be more problematic.

If the (Payload) WG is okay with this limitation (and the limitation of a maximum of 120 ms packets), I think the internal-framing-only is okay; if not, we might need external framing as well. (I appreciate that you don't want to change the Opus bitstream proper, at this point.)

--
Jonathan Lennox
[e-mail]