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>
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>
Due the crappy issue of classes having to be unique,
we cannot even have classes with identical content,
otherwise the compiler or linker is free to merge them,
giving the same result and bugs as if we had only one class.
Besides redesigning the option code to handle this correctly
I see only the option of requiring any two classes to have
different names, but the list of requirements for
AVClasses is getting kind of unmanageable.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Where necessary use memcpy instead.
Thanks to Giorgio Vazzana [mywing81 gmail] for
spotting this loop as the cause for the bad
performance.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This is the first 2 MB of the official test7.mkv.
That length seems to be enough to detect the bugs
we had in our code so far.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Regression since c10d498bfd.
Unfortunately ff_thread_get_format can only be called from
a separate decode thread, running it during init will fail.
Fixes for that are welcome, for now just revert back to
calling avctx->get_format directly, which is correct
but having to decide on a case-by-case basis which approach
to use is a bit messy.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Just like get_buffer, get_format should not be called from a different
thread if thread_safe_callbacks is not set.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
With the current code it fails due to running out
of registers.
So code the store offsets manually into the assembler
instead.
Passes "make fate-dts".
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
- Make MultiByteToWideChar fail when it encounters invalid encoding.
Without this, invalid characters might just be skipped
- When MultiByteToWideChar fails, assume the file name is in CP_ACP
and open it via normal open function, even when the file will be
written
- When malloc fails return error instead of crashing
Signed-off-by: Martin Storsjö <martin@martin.st>
In order to match Linux behaviour better our Windows-specific
open() replacement should disable Windows default file locking.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is admittedly kind of pointless since usually -f image2pipe
can be used for the purpose, but this is more user-friendly.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Otherwise ffmpeg -formats claims that we only support demuxing
of that format.
To keep compatibility the struct could be duplicated instead,
but this seems almost like overkill for such a rare format.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
- Make MultiByteToWideChar fail when it encounters invalid encoding.
Without this, invalid characters might just be skipped
- When MultiByteToWideChar fails, assume the file name is in CP_ACP
and open it via normal open function, even when the file will be
written
- When malloc fails return error instead of crashing
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
As far as I can tell the code should not change behaviour
depending on locale in any of these places.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Previously avctx->hwaccel would have been set to a dummy value,
now an explicit check is necessary instead.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
As the name indicates we can't just assume what the
"opaque" field contains.
This fixes a crash in third-party applications see e.g.:
http://bugzilla.mplayerhq.hu/show_bug.cgi?id=2126
This fixes also FFmpeg trac #2293, which is a different
third-party application.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Will be used in future patches, together with the
variable that allows checking whether the lock is held.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The description of AV_LOG_PANIC 100% matches what av_assert
does, while AV_LOG_FATAL does not really.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
It would be called while registering the codec, which means
it needlessly wastes memory when it is never used.
Instead do the work when first opening the codec.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This is intentional (and a reason why fast usually should not be used),
but a few people sent patches to "fix" this recently so it would be
better to document this.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Not all applications (e.g. MPlayer) set block_align, and
when using a different demuxer it might not even be
easily available.
So fall back to selecting mode based on bit rate as before
if block_align has not useful value.
It can't be worse than failing to decode completely.
(cherry picked from commit 1d0d63052b)
CC: libav-stable@libav.org
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
This fixes playback of DVB subtitles in
http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1065/Test1.wtv
in MPlayer.
FFplay is not affected since it assumes that the subtitles
are scaled to match the video - but this usually isn't the
case after rescaling the video and stream-copying subtitles.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Closed caption data is definitely not teletext.
Since it contains a EIA-608 compatibility stream,
the EIA_608 codec ID is at least not completely wrong.
Fixes subtitle playback in MPlayer with the sample in
trac ticket #1482.
To fix the ticket itself I expect FFmpeg will need
a closed-caption to SRT decoder first.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Using the malloc variant avoids pointless memcpy on size
increase and simplifies handling allocation failure.
Also change code to ensure that allocation, bswap and bitstream
reader all use the same size, even when the packet size is odd
for example.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Using the malloc variant avoids pointless memcpy on size
increase and simplifies handling allocation failure.
Also change code to ensure that allocation, bswap and bitstream
reader all use the same size, even when the packet size is odd
for example.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
About 30% faster on 32 bit Atom, 120% faster on 64 bit Phenom2.
This is interesting because supporting P16 is easier in e.g.
OpenGL (can misuse support for any 2-component 8 bit format),
whereas supporting p9/p10 without conversion needs a texture
format with at least 14 bits actual precision.
The shiftonly == 0 case is not optimized since the code is more
complex and the speed gain less obvious.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The previous method of having to initialize it outside lead
to incorrect code: even if it was initialized, it usually was
only initialized once, thus a packet that could not be matched
to any stream would just be processed with the return values
from the previous call.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Also slightly more correct behaviour in case streams_left for
some reason is 0 from the start.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The previous validity check seems to work only for some
(presumably older) files, in current versions the first bytes
now contain the data size.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Set picture type before calling get_buffer.
This allows the DR application to make better decisions.
It also fixes a resource leak in case of missing reference frames
since it would call get_buffer but never release_buffer.
Also use FFSWAP to ensure that the AVFrame is properly initialized
in the next get_buffer (in particular that data[0] is NULL).
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Set picture type before calling get_buffer.
This allows the DR application to make better decisions.
It also fixes a resource leak in case of missing reference frames
since it would call get_buffer but never release_buffer.
Also use FFSWAP to ensure that the AVFrame is properly initialized
in the next get_buffer (in particular that data[0] is NULL).
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Using release_buffer and get_buffer as currently might
not prefer the previous frame contents which the
decoder relies on.
This leads to horrible playback in players using direct
rendering like MPlayer.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Manually remove that flag again for formats that read an arbitrary
amount of data and thus truncation is not an error.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Currently it always exits with an error when more than
one position is specified.
Fixes trac issue #1266.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
It is possible that just extending the RMMuxContext.streams
array would avoid it.
It is also possible that two audio streams will fail to mux
correctly as well, though at least it should not crash for
this reason.
I do not feel like checking either of these.
This patch fixes trac issue #1022 (at least it makes it
exit with a proper error message instead of crashing).
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Also fixes an (incorrect) "control reaches end of non-void function"
warning with some compilers.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This should fix the FATE test on ARM (not tested),
but it should also detect alpha values like 2^128
reliably as invalid which would be another out-of-range
case with implementation-dependant behaviour.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This also avoids an issue with parallel make in some
cases never building asynth-16000-1.sw.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
One rule can be used to generate all asynth files.
Requires renaming the mapchan files though.
Also switch to using the .wav variants for mapchan
while changing the name anyway, this allows getting rid
of the explicitly specified format.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Do not pointlessly call ff_alloc_packet multiple times,
and fix an infinite loop by clamping the maximum
number of bits to target in the algorithm that does
not use lambda.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Reimar DöffingerandCarl Eugen Hoyos
