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>
Overwriting the av_malloc etc. functions is not easily
possible anymore, even for systems that support overriding
symbols in shared libraries in principle.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This replaces the matroskadec one with the same name.
The advantage is not only easier reuse in other demuxers
but also that we can make the decisions after the parser.
This fixes seeking in files that mark the keyframes incorrectly,
for example the file in track ticket #1003.
The matroska variable is still kept to be able to complain
about such broken files.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
0-sized packets are used to implement variable fps.
However there seems to be a variation where these are not
even stored in the main file but as 0-size index entries
only.
This fixes the sample in trac issue #957, it now plays both
the same ways as in MPlayer and in a way that looks correct.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
They will only cause us to skip writing the Xing header,
not cause any serious breakage.
Related to trac issue #1027.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
All code should use the local variable, the
AVCodecContext might not yet have the updated value.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Fixes potential out-of-bounds writes.
This is mostly possible when muxing ALS files where from
an extradata size of about 1050 put_bits would write data
outside the buffer.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
For the FATE test sample used, this only avoids a warning
message.
However for other samples like al05_44.mp4 the converted
file can be played only after this fix.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This will only work for DSEs that are first in a packet, but
that is enough to fix handling of the reference files in
fate-suite/aac (though most of them still have other issues).
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Otherwise for muxers like e.g. latmenc that never call
avio_flush (and do not have a write_trailer function)
a part of the data will always be missing.
Also update references for the voc muxer, which was also
buggy before and did not write out all data.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Previously it would just silently write out incorrect data.
This also fixes a potential integer overflow in the allocation.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
"Fix" in so far as at least it will no longer overread and possibly
crash and makes somewhat sense, but no idea whether there is anything
that can play the resulting files (FFmpeg can't).
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
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>
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>
Decode output must be converted to rgb24 to avoid CRC difference
due to palette being stored in machine endianness.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Since those are pseudo-palette formats, swscale does not write
into data[1], swscale must initialize the palette properly itself.
This lead to frames that actually decoded as all-gray before.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This fixes that the GIF encoder crashes with it because
it has no palette.
And the arguments for the pseudopalette apply to gray8 as
much as to RGB8 etc.
In addition the changes required in lavfi should be needed anyway
when adding support for RGB8 etc.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
We can't use whether the input format is paletted to decide that
the output format has a palette in data[1], too, that makes no sense.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
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 makes it easy to allow people to run tests that are disabled
(e.g. because they are broken) without having to hack Makefiles
by adding the test name to FATE_TESTS-no.
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>
Since we cannot specify decode parameters (and also because
it is better in principle) the 1-channel reference file
needs to be enabled, too.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Remove it from two places where it is useless, do not apply
it to the encode command and make it apply to the output
instead of the input of the decode command.
Should fix the dpx test.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
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>
The PSNR values are of varying usefulness, though at least
the DTS and AAC ones are useful with the right shift value.
Note: due to usage of floats some of these may fail on other
architectures.
In that case they should be converted into a CMD = stddev
FATE test, but it seems useful to try this way first.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Do not pointlessly call ff_alloc_packet2 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>
Reimar DöffingerandMartin Storsjö
