Hi,
for some research application I want to simulate ultra low delay (<= 5 ms) (speech) streaming using the OPUS codec.
To make sure everything is right I got a question:
If I use the opusenc/dec executables with a framesize of 2.5 ms does that mean the audio data could also be streamed in 2.5 ms frames? I.e. is that equivalent to cutting the audio into 2.5 ms slices (as I would in a live application) and then applying the OPUS codec?
for some research application I want to simulate ultra low delay (<= 5 ms) (speech) streaming using the OPUS codec.
To make sure everything is right I got a question:
If I use the opusenc/dec executables with a framesize of 2.5 ms does that mean the audio data could also be streamed in 2.5 ms frames?
Yes, forcing a framesize of 2.5 ms in opusenc is for all practical purposes equivalent to what you would get via RTP (there will be very minor differences, but they pretty much irrelevant for the purpose of a comparison). Note that if you care so much about the delay, you might also want to use something like --hard-vbr because bitrate spikes could cause small spikes in delay (that's not specific to Opus, just networking in general) if your bandwidth is constrained (and if it isn't constrained, then why aren't you using a higher bitrate).
I.e. is that equivalent to cutting the audio into 2.5 ms slices (as I would in a live application) and then applying the OPUS codec?
I mean you need to be aware that Opus uses overlap between frames. So 2.5 ms frames aren't fully independent of each other. That's why 2.5 ms frames give you a 5 ms total algorithmic delay. But aside from that, as I said above, opusenc is good enough to simulating what you're after.
Great, exactly the answer I was looking for :)
I think this clears everything up!
"and if it isn't constrained, then why aren't you using a higher bitrate"
The application has latency and energy consumption constraints, so low bit-rate is of interest