On 2016-12-30 5:20 AM, Vittalprasad wrote:
> when i inspect the encoded file, it looks repacketiser fails to pack a
> encoded frames of different modes( HYBRID, CELT) in a single packet.
>
> 1. Does above mentioned issue is the current limitation of Repacketiser?
It is a limitation of the codec. Each Opus packet starts with a single
header before some number of compressed frames, so those frames must
necessarily share a coding mode, audio bandwidth, and decoded duration.
For details, see https://tools.ietf.org/html/rfc6716#section-3.2
The reference encoder uses uniform 20 ms frames by default, so duration
mismatch wouldn't be a problem in your example, but places where the
encoder switched modes will cause problems if not handled specially.
> opus_repacketizer_cat() failed: corrupted stream
If you're following repacketizer_demo.c, this error message is
misleading. According to the docs, `opus_repacketizer_cat()` returns
`OPUS_INVALID_PACKET` if:
The packet did not have a valid TOC sequence, the packet's TOC
sequence was not compatible with previously submitted packets
(because the coding mode, audio bandwidth, frame size, or channel
count did not match), or adding this packet would increase the total
amount of audio stored in the repacketizer state to more than 120 ms.
That is clear enough, but the demo code just calls `opus_strerror()` on
the return value which prints a generic interpretation of that code.
> opus_demo -e audio 48000 1 32000 female1.pcm female1frame.opus
Note that opus_demo doesn't make a .opus file as described in RFC 7845.
It uses its own custom encapsulation to simplify testing.
-r