The r10k and avrp decoders would previously store 12 bit precision
for the blue channel, which is inconsistent and probably not a
desirable behaviour.
Now the 2 unused extra bits are set to 0.
This is possibly not ideal either as RGBA1010102 format has the same
layout but stores alpha in these bits, thus explicitly setting them
to 1 might be preferable.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Also adds a lot of infrastructure necessary for it.
Some of it is a bit ugly though.
Increases binary size for hardcoded tables by about 12 kB,
which is about 15 kB from qdm2_table minus data and code
saved that was only used for creating it.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Should improve cache usage and reduces stack usage.
Also reduces number of copies in case many levels
have the same number of bits.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Ideally the compiler could figure this out on its own,
but it seems it can't.
An alternative that would avoid the messy explicit memcpy
would be to use a sub-struct for the parts that should
be preserved, which can then simply be assigned.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
As far as I can tell the value can never go outside
the int16_t type.
And especially the cost of the initialization is
reduced quite a bit by making it smaller.
Overall decoding speedup not measurable though.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
11674 -> 10877 decicycles on my Phenom II.
Overall speedup was unfortunately within measurement error.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This is a regression, previous code did not require
users to set the profile to use VDPAU.
In addition, ASP is a superset of SP, so there is not
even a good reason to require it.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This avoids several issue like calculating sum/maxcoef
incorrectly due to adding up matrix entries that will
be overwritten, as well as out-of-range writes to
s->matrix if the maximum allowed number of channels is used.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
We only actually need to use a tiny part of it.
Unfortunately we seem to have no real test coverage on
the code, so this is a bit risky.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
For sbr_qmf_window_us there is even a question if it maybe
should be fully hardcoded all the time.
Since half of it is coded, it ends up in .data and not .bss.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
A bit more complex than e.g. adding it to the context, but
using the context for something that will be used only during
initialization seemed a bit wasteful.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Together with the switch to RL_VLC this results in
a speedup of about 30% in this inner loop.
Overall speedup only relevant for medium to high bitrate
streams.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Unfortunately this was not explicitly documented and thus
might be risky.
But all uses I could find in FFmpeg and one in VLC had a memleak
in these cases, and I could not find any that relied on the previous
behaviour.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This allows getting rid of the many, slightly differing, implementations
of basically the same thing.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
It is obviously nonsense since it produces wrong results
or even crashes (crashes should be encode-only though).
Fixes trac issue #1092.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes these errors with nasm:
libavcodec/x86/lossless_videodsp.asm:86: error: invalid combination of opcode and operands
libavcodec/x86/lossless_videodsp.asm:88: error: invalid combination of opcode and operands
I don't know whether movd or movq was meant, but either way
maskq vs. maskd must match the mov size.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
These are not supported by all compilers (gcc 2.95 but also older SPARC
compilers, see gcc bug #33304 for example), and there is no real need for them.
One use of this feature remains in libavdevice/v4l2.c which can't be
replaced quite as easily.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Some older compilers might have particular trouble with them,
and they do not really seem worth it to me.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
In particular the mutex initialization for example won't actually
compile with e.g. gcc 2.95.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Since we have this compat/va_copy.h header already we might just as well make
use of it for more than one compiler.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This allows installing into e.g. /usr/lib/ffmpeg and binaries linked
against ffmpeg will pick these .so file while binaries linked against
some fork or different version will pick the libraries in /usr/lib.
There will be still some issues for binaries that (indirectly) end up
depending on multiple variants, but for the simpler cases it should allow
different applications to use different (compatible) variants that
are installed at the same time.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Generate extradata with SPS/PPS based on container dimensions.
Authors of this commit are: Reimar and Thomas Mundt
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Aligning the tables reduces the amount of code generated on
e.g. ARM as the offset constant then has few enough set bits
so it can be encoded inside a single instruction instead of 2.
Ideally all should be declared aligned, but the DECLARE_ALIGNED
macros does not work with pointer tables, thus also reordered
the tables.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Without this, it is 0/0 by default, which is not allowed.
This sets it to 0/1, which means "undefined".
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
For codecs where decoding of a whole plane can simply
be skipped, we should offer applications to not decode
alpha for better performance (ca. 30% less CPU usage
and 40% reduced memory bandwidth).
It also means applications do not need to implement support
(even if it is rather simple) for YUVA formats in order to be
able to play these files.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Issues with the code:
1) The skip_bits_long breaks packed B-frames since we skip
of the packed frame, even for VDPAU.
2) Calling ff_h263_find_resync_marker_reverse is nonsense for MPEG-4,
and for H.263 the only code using this (vaapi_mpeg4) explicitly reverts
this change!
3) mb_x/mb_y are always 0 when vaapi_mpeg4_decode_slice, so doing
computations with them is just obfuscation
4) due to not updating mb_y the code would always go into the error
resilience case, causing nonsense error messages and maybe further
issues.
While tested to fix the data provided to the decoder in case of
VDPAU so it is the same as for the non-hwaccel code, the VA-API code
was not tested to still work, and adding regression testing even
as a quick hack is much more complicated for it.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Avoid overwriting the bitstream buffer data before we
have ended processing the frame.
This is necessary to fix hwaccels which might try to use
the buffer during the end_frame call.
I am not sure but it is possible this could even trigger
a use-after-free if the av_fast_malloc allocated a new buffer.
This would require that decode_slice did not wind the bitstream
forward all the way to the end, which does not currently happen in
normal streams.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Seeking in certain broken files would cause ogg_read_timestamp
to fail because ogg_packet would go into a state where all packets
of stream 1 would be discarded until the end of the stream.
Bug-Id: 553
CC: libav-stable@libav.org
Signed-off-by: Jan Gerber <j@v2v.cc>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Using VDPAU correctly means checking for preemption
and possibly regenerating the context all the time.
With the current API there is no context or other
user-defined pointer and thus this in not possible
during decoding unless using some hack like global
variables.
The need to reinitialize both surfaces and even function
pointers makes handling preemption even more difficult.
This patch introduces a new render2 function that gets
both the AVCodecContext and AVFrame in addition,
in both the user can store additional opaque data.
This allows even advanced approaches like keeping a
"generation counter" for the surfaces so they can be
regenerated on the fly and efficiently.
In addition, the function has a return value that will
be passed through all the way instead of being silently
ignored as for the current render function.
Unfortunately the HWAccel API has no way of providing
API/ABI compatibility, so a currently disallowed
state (render pointer being NULL) is used to extend it.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Reimar Döffinger
