I have one opus file, 2 versions of ffmpeg.
I use each ffmpeg to convert the file to s16le (which I'm assuming is raw PCM audio)
The results differ.
why?
I have one opus file, 2 versions of ffmpeg.
I use each ffmpeg to convert the file to s16le (which I'm assuming is raw PCM audio)
The results differ.
why?
@wolf480pl @icedquinn again, on second^2 thought, in case of Youtube that wouldn't make sense, because they are streaming over TLS, which is not lossy. It is for use cases where the protocols are specifically built with dropouts in mind, like videoconferencing.
@wolf480pl @icedquinn possibly? from the sound of it, the encoder would have to opt-in for that, and I barely know what I'm talking about here.
@amonakov @icedquinn
streaming over networks?
like youtube?
So if you youtube-dl the opus audio from a youtube video without reencoding, it'd have that?
@wolf480pl @icedquinn hm, but on second thought, that is specifically for streaming over networks, and wouldn't be used in conventional encoding?
@wolf480pl @icedquinn but even without floating-point, you can get different decodes if your other version of ffmpeg doesn't know about the clever backward-compatible upgrade:
@icedquinn hmm... do you know if opus uses floats?
@wolf480pl @icedquinn I can confirm that, both the ffmpeg decoder and reference library use floats; the reference library can be configured to avoid floating-point arithmetic, but that's not the default.
@icedquinn
> some chinese people were using that to play games around the firewall
not just chinese people
also, when reading @amonakov 's screenshot for some reason I didn't notice that "lossy" referred to the network, not to the codec.
But then, if the extra data is only some form of error-correcting code, why would it affect the decoded stream when I have the complete encoded stream with no holes in it?
@amonakov @icedquinn
I looked at the opus test vectors, and looks like they don't check it bit-by-bit, instead they use opus_compare, which seems to calculate per-band energy in a sliding window manner, and then compare those with some epsilon or sth...
@icedquinn @wolf480pl I don't think it's academic, checking decoded data is how you catch unintended bugs; floating-point decoding can be reproducible if you know what you're doing
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.