- Feb 13, 2025
-
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Yunho Huh authored
Change-Id: Ib016fc8f0066980e3e5122b3f286680adc228ff9 Signed-off-by:
Jean-Marc Valin <jeanmarcv@google.com>
-
Yunho Huh authored
The exp2 function was approximated using lolremez, achieving an accuracy of less than 2*10^-7 within the range of 0 to 1. Signed-off-by:
Jean-Marc Valin <jeanmarcv@google.com>
-
Yunho Huh authored
Change-Id: Ibd0d16918272cb568923d384475e139dc312c61b Signed-off-by:
Jean-Marc Valin <jeanmarcv@google.com>
-
Yunho Huh authored
The log2 function was approximated using lolremez, achieving an accuracy of less than 1.4*10^-8 within the range of 1 to 2. Signed-off-by:
Jean-Marc Valin <jeanmarcv@google.com>
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
Convert to 16 bits only at the very end
-
- Feb 12, 2025
-
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
Compensates for the spectral leakage and the fact that we don't have an explicit masking curve.
-
Jean-Marc Valin authored
Detecting tones can help us prevent the encoder from getting confused by them.
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
Jean-Marc Valin authored
-
- Feb 10, 2025
-
-
Timothy B. Terriberry authored
Git will now remember it for us forever. Signed-off-by:
Jean-Marc Valin <jeanmarcv@google.com>
-
Timothy B. Terriberry authored
Even if it is followed by repeated short extensions with payloads. We track the total size of the short extension payloads that need to be repeated, and remove that from the available space for the last long extension. This means we can no longer use L=0 on a repeat to skip coding a frame separator when the extensions to be repeated contain a long extension followed by one or more short extensions with payloads (and there are no more non-repeated extensions in the current frame, but there are extensions in the next frame), but this case seems uncommon, and hard to explain. The savings from always being able to skip coding a length when the final extensions are repeated extensions with at least one long extension is likely higher. We can still skip a frame separator if we repeat only short extensions. Also update existing tests and add a test for the case where we do not have enough space for the repeated short extensions after the last long extension. Signed-off-by:
Jean-Marc Valin <jeanmarcv@google.com>
-
Timothy B. Terriberry authored
This avoids the need to code a frame separator in the case that the last repeated extension is a short extension, and the next non-repeated extension is in the following frame instead of the current one (saving one additional byte). Also add tests for both encoding and decoding this. Signed-off-by:
Jean-Marc Valin <jeanmarcv@google.com>
-
Timothy B. Terriberry authored
This gives more confidence that the generation code always produces output that the parsing code can parse. Signed-off-by:
Jean-Marc Valin <jeanmarcv@google.com>
-
Timothy B. Terriberry authored
Also adds tests which exercise generating repeated extensions as well as the count_ext() and parse_ext() API for parsing extensions in frame order. Signed-off-by:
Jean-Marc Valin <jeanmarcv@google.com>
-
Timothy B. Terriberry authored
Right now, opus_packet_extensions_parse() returns the extensions in the order they appear in the packet, which is no longer necessarily in frame order. This adds a new (still private) API that returns parsed extensions in frame order, even when repeated extensions are used. Nothing has been converted to use this new API yet. Signed-off-by:
Jean-Marc Valin <jeanmarcv@google.com>
-