Adding an arbitrary amount of padding bytes at the end of the
ID3 metadata fixes cover art display for some software (iTunes,
Traktor, Serato, Torq).
For reference (ID3 metadata):
[ Apic frames ] -> cover doesn't show up
[ Apic frames, Padding ] -> ok
[ Apic frames, ID3 frames ] -> ok
[ ID3 frames, Apic frames ] -> cover doesn't show up
[ ID3 frames, Apic frames, Padding ] -> ok
This fixes a TODO item and unifies both decoders structures
It also fixes undefined behavior due to aliasing violations
I choose 2 fields instead of a union because mistakely using the
wrong type with a union will lead to hard to debug "wrong output"
while with 2 fields mistakely using the wrong type will crash
with a null pointer derefernce which is much easier to debug
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '36a7df8cf1115aa37a1b0d42324ecde5ab6c2304':
arm: Only build the FFT init files if FFT is enabled
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Based on the work of Jeff Moguillansky <Jeff.Moguillansky@am.sony.com>.
See thread:
Subject: [FFmpeg-devel] x11 output device for libavdevice
Date: Wed, 10 Apr 2013 23:10:47 +0000
* commit '9b9b2e9f3036abfd42916bcf734af14b4cb686aa':
build: arm: cosmetics: Place all OBJS declarations in alphabetical order
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '701966730ce10290fd49c5ccedd73f505680f764':
vmd: drop incomplete chunks and spurious samples
Conflicts:
libavcodec/vmdav.c
2 of the changes are replaced by assert0s, as they should
be impossible.
The actual bug is likely caused by a invalid block_align
which is checked for and thus impossible in ffmpeg.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '91a6944e56236234f0a7ba162404665753cbcb51':
vmd: use the PALETTE_COUNT constant uniformly
Conflicts:
libavcodec/vmdav.c
No change as the changed line does not exist in ffmpegs vmdav.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
A few of the h264qpel neon functions are shared with other
hpeldsp functions in this file.
This fixes standalone compilation of the h264 decoder on arm.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is necessary since the switch to floating point
input means there is no longer sufficient input data
validation.
There is a good chance that other encoders are affected
by similar issues.
This problem can be triggered by trying to encode
extremely large values and probably also with Inf and
possibly also NaNs.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Odd chunk size makes no sense for stereo and incomplete chunks are
not supported.
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
