| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
In some cases, in particular if several blocks are needed because of
the channel layout (e.g. 2.1), the information used to write the
trailing bits terminating the sample data was not reset.
This would cause potential desync on the decoder, although decoded
samples were actually mostly fine.
Fixes ticket #3879.
|
| |
|
|
|
|
|
| |
It was only validating that normal data wasn't filling the buffer.
However, extra data may be written afterwards.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
|
|
|
|
|
|
|
|
| |
Currently, the encoder will try to reduce it down to 150000, but the
decoder will complain starting at 131072 (WV_MAX_SAMPLES). Therefore,
change the loop limit.
Fixes ticket #3881.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
|
|
|
|
|
|
| |
bytestream2_* will not cause buffer overflow, but in that case, this means
the allocation would be incorrect and the encoded result invalid. Therefore,
assert no overflow occurred.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
|
|
|
|
|
|
|
|
|
| |
The allocation didn't account for headers, that can be easily 79 bytes.
As a result, buffers allocated for a few samples (e.g. 5 in the original
bug) could be undersized.
Fixed ticket #2881.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
|
|
|
|
| |
Found-by: CSA
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
|
|
| |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
|
|
|
|
| |
Fixes CID1108609
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
| |
|
|
| |
Signed-off-by: Paul B Mahol <onemda@gmail.com>
|
| |
|
|
| |
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
|
|
|
Signed-off-by: Paul B Mahol <onemda@gmail.com>
|
