Re: [codec] Multi-mode frame concatenation

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

On 07/29/2011 01:12 PM, Ralph Giles wrote:
> On 28 July 2011 17:48, Benjamin M. Schwartz wrote:
> 
>> """
>> If M == 49, p == 0, and v == 1, then the packet is a "multi-mode packet".
>>  The decoder MUST read the next byte to determine the true values of M, p,
>> and v.  Decode shall then continue as normal, except that each frame shall
>> be interpreted as a Code 0 packet.  Decoders MUST NOT continue decoding
>> the packet if any frame indicates a code other than 0.
>> """
> 
> To clarify, the spec limits code 3 packets to 48 frames, so M > 48 is
> currently rejected, and we have (2^4 - 2 = 14) extensions to the Opus
> framing we can signal by allowing additional values here while
> maintaining backward compatibility with draft-ietf-codec-opus-07.

For some definitions of backwards compatibility, yes.  The draft's text
indicates that this extensibility is deliberate.  I'm not sure where you
get 14; I get (64-49)*4 = 60, at a minimum.

> Your proposal for M = 49, p = 0, v = 1, or Opus frame count byte = 177
> is to set the multimode extension flag in the decoder state, and then
> read the next byte as the Opus frame count byte. Then by "each frame
> shall be interpreted as a code 0 packet" you mean the frames are read
> according to the second frame count byte, with lengths if v = 1 and
> without if v = 0, but instead of reading undecorated frames, the
> decoder will read a toc byte at the start of each frame, like so:
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |1|1|s| config  |     49    |0|1|     M     |p|1|  Pad length   :
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      : N1 (1-2 bytes): N2 (1-2 bytes):     ...       :     N[M-1]    |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |0|0|s| config  |                                               |
>      :               Compressed frame 1 (N1 bytes)...                :
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |0|0|s| config  |                                               |
>      :               Compressed frame 2 (N2 bytes)...                :
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      :                              ...                              :
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |0|0|s| config  |                                               |
>      :                     Compressed frame M...                     :
>      |                                                               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      :                     Padding (Optional)...                     |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                       A VBR multimode packet
> 
> 
> In any case, multimode packets would still be limited to 48 frames,
> it's just that each would have a TOC byte so mode changes could be
> signaled without forcing a packet boundary. Is that accurate?

This is all extremely accurate.  I had originally intended (following the
language in your diagram) for Compressed frame 1 to consist of N1-1 bytes,
so that its entirety (including the TOC byte) had size N1.  However, I now
see that your version is superior, as otherwise it would be impossible to
represent the max-size frame (1275 bytes, or 1276 with the TOC byte).