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>
Allows avoiding the buffer when using avio read, write and seek functions.
When using the ffmpeg executable -avioflags direct can be used to enable
this mode for input files, but has no effect on output files.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This fixes crashes when copying a data track as in trac
issue #236.
No proper timecode tracks will be written though.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This patch fixes the sample from trac issue #522.
The issue is that the mov demuxer insists on using its
calculated sample_size (which is nonsense for old-style tracks)
instead of the one encoded in the track.
The old raw audio code should be using the value in stsz, because
the size of a single sample never makes sense for the size of
a full audio packet, whereas the new code will multiply the
sample size by the chunk size, so it should use the calculated value.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This patch fixes the sample from trac issue #733.
The issue is that the size of the trak elements is coded
too large, so that the next trak element would be parsed
as part of the first and truncated incorrectly.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The previous condition of 0 page size was wrong,
that would disable the mechanism for all frames at
a start of a page, thus some keyframes still would not
get their own granule.
The real problem is that header packets must not be flushed,
but they have (and must have) 0 granule and thus would
be detected as keyframes.
Add a separate parameter to mark header packets.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
This depends on the proposed parser change for 0-size packets
in previous mail, otherwise video now plays far too fast.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Currently, the duration of those packets is just discarded
when enabling parsing, thus the output of the Metal Gear Solid
demuxer breaks completely when just setting AVSTREAM_PARSE_HEADERS.
The result will not be correct if a parser creates a delay even
with PARSER_FLAG_COMPLETE_FRAMES and there might be other cases
where it does not work correct, but just discarding them as it
is done currently seems worse.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This might even have prevented the compiler from some optimizations,
since both signed and unsigned types are used for the dezigzag tables/
table pointers, and if a branches uses both the compiler needs to
create more complex code.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
See trac issue #217.
Only the dsf field seems to be used to distinguish between PAL and NTSC.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
They were moved into code under HAVE_YASM and most of them
even into completely disabled code with no reason given
for that in the commit message.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Allows working around issue #605.
Note: as a side effect this fixes that -vsync drop
as far as I could tell would not drop pts/dts values
when duplicating frames or when flushing encoder delay.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
It is currently only handled in the parser code for WMV/ASF style
header, but not the one used in the bytestream format used when
muxed into MPEG-TS as on e.g. BluRay.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This is even potentially faster in this use-case.
Should fix AAC SBR decoding on machines with SSE but not
SSE2, fixing track issue #1041.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The two samples both have stype 0.
Without this extra check, the code breaks 4:2:2 dvsd
(stype 4), since that has the same resolution.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Since the values are floats, using the float operations
makes sense, improves performance on some CPUs and
makes the code SSE compatible instead of needing SSE2.
Based on suggestion by Jason.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
movq from SSE register _to_ memory is an SSE2 instruction.
Use the SSE movlps function instead that does the same thing.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Reimar Döffinger
