Thanks Jean-Marc and Benjamin for the answers.
One follow-up question. If I use a repacketizer as Jean-Marc suggested by
combining two 60ms frames to form a 120ms frame, without extracting individual
frames and using a new TOC, I would need to have a "de-packetizer"
that does the exact opposite of repacketizer. De-packetizer would need to
separate this 120ms frame into two 60ms frames and feed them individually to the
decoder. In other words, the OPUS decoder can't decode an input that has
two or more TOCs, right?
Regards,
Chris
-----Original Message-----
From: Jean-Marc Valin [mailto:jmvalin at jmvalin.ca]
Sent: Saturday, October 26, 2013 2:34 PM
To: Wang, Chris; opus at xiph.org
Subject: Re: [opus] libopus API question - 120ms encoding
On 10/26/2013 01:11 PM, Wang, Chris wrote:> A simpler question. How does opus_encode() generate packets of 20ms
> (SILK-only or Hybrid)? Concatenating two 10ms frames or doing it
> straight with just one 20ms frame?
Just one 20 ms frame. It always returns a single frame except when it just
can't (e.g. 60 ms CELT).
> From your explanations below, opus_encode() will concatenate 2 or 3
> CELT-only or Hybrid frames for 40 or 60ms packet, respectively. That
> is based on concatenating 20ms frames, right?
Right.
> Is 60ms the largest packet opus_encode() can generate?
Yes.
> In order to
> get packets of up to 120 ms by combining multiple frames as described
> in RFC6716 clause 2.1.4 one would need to use the "repacketizer".
> That is if I want to have a 120 ms packet, I would need to take two
> 60 ms packets generated by opus_encode(), extract out the compressed
> frames from each packet, concatenate them and put on a new TOC with
> frame count code "c" set to 1.
Well, no need to extract as a separate step. The repacketizer can handle
concatenating two packets that each contain multiple frames. That being said, if
the encoder switched mode in between (usually very rare), then the repacketizer
will not be able to generate a 120-ms frame.
Cheers,
Jean-Marc
> Regards,
>
> Chris -----Original Message----- From: opus-bounces at xiph.org
> [mailto:opus-bounces at xiph.org] On Behalf Of Jean-Marc Valin Sent:
> Friday, October 25, 2013 7:19 AM To: O'Connor, Kevin; opus at xiph.org
> Subject: Re: [opus] libopus API question - 120ms encoding
>
> The general ideao of opus_encode() is indeed to encode a single frame.
> However, there is an exception for 40 and 60 ms because only one mode
> (SILK-only) has this frame size. The original code would automatically
> force SILK-only mode on 40 and 60 ms, but that was suboptimal for mode
> switching. This why opus_encode() can now generate packets that
> concatenate 2-3 CELT-only or 2-3 hybrid frames when called for 40 or
> 60 ms. This is the only exception. It will
> *not* encode 120 ms, nor 30 ms frames from concatenating 3 10-ms
> frames. For anything else, you need the repacketizer.
>
> Cheers,
>
> Jean-Marc
>
> On 10/24/2013 01:45 PM, O'Connor, Kevin wrote:
>> The libopus encoder's opus_encode() method is documented as
"Encodes
>> an Opus frame". Does that mean that it always produces a single
Opus
>> frame (i.e. the number of frames in the TOC byte will always be 0)?
>> It's not clear from the documentation, but the fact that it cannot
>> produce a 120ms Opus packet makes me wonder if that was the intention
>> and any multi-frame Opus packets must formed outside the libopus
>> encoder (e.g. the Repacketizer).
>>
>>
>>
>> If that's not the case and opus_encode() can produce multi-frame
Opus
>> packets, why is it limited to 60ms Opus packets?
>>
>>
>>
>> Kevin O'Connor
>>
>> Interacive Intelligence, Inc.
>>
>>
>>
>>
>>
>> _______________________________________________ opus mailing list
>> opus at xiph.org http://lists.xiph.org/mailman/listinfo/opus
>>
>
> _______________________________________________ opus mailing list
> opus at xiph.org http://lists.xiph.org/mailman/listinfo/opus
> _______________________________________________ opus mailing list
> opus at xiph.org http://lists.xiph.org/mailman/listinfo/opus
>