| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| optimize.diff | =================================================================== | no | ||||
| amd64-64bit.diff | =================================================================== | no | ||||
| Provide-Thumb-2-alternative-code-for-MAD_F_MLN.diff | "rsc" doesnt exist anymore in thumb2 diff --git a/fixed.h b/fixed.h index 4b58abf..ba4bc26 100644 |
Dave Martin | no | |||
| libmad.thumb.diff | use "adr" instead of "add" to make code ready for thumb2 | Konstantinos Margaritis <markos@debian.org> | no | |||
| mips-gcc4.4.diff | Different constraints for mips with gcc-4.4 This asm constraints has been removed from gcc 4.4, that's why it was not failing before. See http://gcc.gnu.org/gcc-4.4/changes.html for more details, including a description of the new way to do it. |
Aurelien Jarno <aurelien@aurel32.net> | no | |||
| md_size.diff | Check the size of the main data The main data to decode a frame can come from the current frame and part of the previous frame, the so called bit reservoir. si.main_data_begin is the part of the previous frame we need for this frame. frame_space is the amount of main data that can be in this frame, and next_md_begin is the part of this frame that is going to be used for the next frame. The maximum amount of data from a previous frame that the format allows is 511 bytes. The maximum frame size for the defined bitrates is at MPEG 2.5 layer 2 at 320 kbit/s and 8 kHz sample rate which gives 72 * (320000 / 8000) + 1 = 2881. So those defines are not large enough: # define MAD_BUFFER_GUARD 8 # define MAD_BUFFER_MDLEN (511 + 2048 + MAD_BUFFER_GUARD) There is also support for a "free" bitrate which allows you to create any frame size, which can be larger than the buffer. Changing the defines is not an option since it's part of the ABI, so we check that the main data fits in the bufer. The previous frame data is stored in *stream->main_data and contains stream->md_len bytes. If stream->md_len is larger than the data we need from the previous frame (si.main_data_begin) it still wouldn't fit in the buffer, so just keep the data that we need. =================================================================== |
Kurt Roeckx <kurt@roeckx.be> | no | 2018-01-28 | ||
| length-check.patch | Check the size before reading with mad_bit_read There are various cases where it attemps to read past the end of the buffer using mad_bit_read(). Most functions didn't even know the size of the buffer they were reading from. =================================================================== |
Kurt Roeckx <kurt@roeckx.be> | no | 2018-01-28 |