summaryrefslogtreecommitdiff
path: root/m4
diff options
context:
space:
mode:
authorTorsten Jager <t.jager@gmx.de>2011-08-13 18:00:54 +0200
committerTorsten Jager <t.jager@gmx.de>2011-08-13 18:00:54 +0200
commit812c8af9bfb91e65a7c85a4281cc9aa0d047d9a7 (patch)
tree6da495011b227495d3f515c863f500d615e4cd7c /m4
parentde7a127259f8341ad8ee9a57cc05f1d43625d972 (diff)
downloadxine-lib-812c8af9bfb91e65a7c85a4281cc9aa0d047d9a7.tar.gz
xine-lib-812c8af9bfb91e65a7c85a4281cc9aa0d047d9a7.tar.bz2
ffmpeg audio crash fix (sse2 alignment)
Certain ffmpeg audio decoders use 32 bit float samples internally (wma, eac3, ...). They are then exported to the calling application as 16 bit integer. That conversion is done by faster sse2 code if your processor supports it. However, sse2 instructions require data buffers to be 16 byte aligned, or hit a segfault otherwise. Plain malloc() / realloc() ensures only 8 byte alignment, giving a 50% chance of a crash. FFmpeg internally uses aligned buffers a lot. It seems to be a good idea to do likewise for input buffers as well, even if current version does not strictly need it yet. Libavutil/av_realloc() has a bug that can break the alignment when enlarging an existing buffer. Thus I included a fixed version of it within ff_audio_decoder.c.
Diffstat (limited to 'm4')
0 files changed, 0 insertions, 0 deletions