If channel residues are have not been decoded from bitstream, they should be
initialized to 0 instead of using values from previous subframe.
This causes bursts of noise in silent parts of some files.
This patch fixes bug #1055
Reviewed-by: Benjamin Larsson <benjamin@southpole.se>
Reviewed-by: Mashiat Sarker Shakkhar <mashiat.sarker@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Add support for all x86-64 registers
Prefer caller-saved register over callee-saved on WIN64
Support up to 15 function arguments
Also (by Ronald S. Bultje)
Fix up our asm to work with new x86inc.asm.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
Currently they end up twice in the binary, since both
encoder and decoder include the header and thus each gets
their own copy.
This is clearly nonsense for the const tables, but shouldn't
be necessary for the RLTable either.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
During failure conditions ff_h264_decode_init() leaks memory
allocated for nal units. Found via valgrind.
Valgrind traces: http://pastebin.com/GqTqxs8T
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Some files contain a few additional, all-0 bits.
Check for that case and don't print incorrect "not supported"
message.
Fixes trac issue #836.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Quite often, the original weights are multiple of 512. By prescaling them
by 1/512 when they are computed (once per frame), no intermediate shifting
is needed, and no prescaling on each call either.
The x86 code already used that trick.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Resolution changes are usually only used to scale with
network bandwidth, the (full) resolution specified in the
RM header really is authoritative.
While I am not sure this is the best solution, it is a
conservative approach that still should fix the most
common cases.
In particular, it fixes aspect with the sample from trac
issue #785 (in MPlayer, ffplay seems to just ignore
sample aspect changes in mid-playback).
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
When decoding LATM, this function will not process extradata
but a different buffer.
It seems this was forgotten to update when LATM support
was added.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This uses the same code as in decode_video also in decode_audio.
Should fix valgrind FATE failures for nellymoser encode test.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
VASliceParameterBufferMPEG2.slice_vertical_position shall express
the slice vertical position from the original bitstream. The HW
decoder will correctly decode to the right line computed from the
appropriate top_field_first and is_first_field flags.
This patch aligns with DXVA's definition, which is what most HW and
drivers expect. In particular, Intel PowerVR (Cedarview et al.) and
NVIDIA (through VA-to-VDPAU layer). Since it looks more complex to fix
binary drivers, I aligned the Intel Gen driver (Sandy Bridge et al.)
to this behaviour, while maintaining compatibility with codec layers
not providing this patch yet.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
If user opted to present fields as they come, then the first field
picture needs to be submitted to the HW for decoding. In particular,
this fixes MPEG-2 decoding of interlaced streams.
Tested on Intel Cedar Trail, Sandy Bridge and Ivy Bridge platforms.
Someone reported on the ffmpeg-devel@ list this also works on DXVA
(Windows) and other Linux platforms (NVIDIA, through the VA wrapper).
This also means a similar patch to non-hwaccel VDPAU may be necessary.
Note: I believe the SLICE_FLAG_ALLOW_FIELD is useless since the first
field shall always be submitted to the HW anyway. Nobody uses HW accels
(dxva, vaapi, vdpau, etc.) without that flag though.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
The format is slightly proprietary.
DVDs use a format of
code byte (0x00, 0x01, 0xfe or 0xff), two data bytes
MOV uses instead
cdat/cdt2 atom, two data bytes
Auto-detecting and supporting both in one decoder is trivial,
so a single codec ID is used.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Diego Biurrun
Michael Niedermayer
Jakub Stachowski
Mans Rullgard
Ronald Bultje
Henrik Gramner
Reimar Döffinger
Dale Curtis
Christophe GISQUET
Sebastien Zwickert
Anton Khirnov
Justin Ruggles
Gwenole Beauchesne