This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes: division by zero
Fixes: integer overflow
Fixes: 43347/clusterfuzz-testcase-minimized-ffmpeg_dem_V210X_fuzzer-5846911637127168
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: lance.lmwang@gmail.com
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
41f213c3bf accidentally added
an unused pixel_format option to the v210(x) demuxers.
Remove it before it really becomes part of the API.
Reviewed-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
As suggested by Andreas Rheinhardt, most code of v210 demuxer is common code
which is duplicated from rawvideodec, so it's better to move v210/v210x
demuxer code to rawvideodec.c and reuse the common code.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Currently, AVStream contains an embedded AVCodecContext instance, which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.
In addition, it is also widely used by the callers as the decoding (when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.
There are multiple important problems with this approach:
- the fields in AVCodecContext are in general one of
* stream parameters
* codec options
* codec state
However, it's not clear which ones are which. It is consequently
unclear which fields are a demuxer allowed to set or a muxer allowed to
read. This leads to erratic behaviour depending on whether decoding or
encoding is being performed or not (and whether it uses the AVStream
embedded codec context).
- various synchronization issues arising from the fact that the same
context is used by several different APIs (muxers/demuxers,
parsers, bitstream filters and encoders/decoders) simultaneously, with
there being no clear rules for who can modify what and the different
processes being typically delayed with respect to each other.
- avformat_find_stream_info() making it necessary to support opening
and closing a single codec context multiple times, thus
complicating the semantics of freeing various allocated objects in the
codec context.
Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores only
the stream parameters exported by the demuxers or read by the muxers.
Also add missing trailing commas, break long codec_tag lines and
add spaces in codec_tag declarations.
Signed-off-by: Martin Storsjö <martin@martin.st>
pixel_format/video_size only apply to 'rawvideo' (==uncompressed) demuxer
and make no sense for the other raw (== containerless) demuxers. Keep
only the framerate option for those.
Also use unique classes for all raw video demuxers
This also lists the objects from those two libraries as internal (by adding
the ff_ prefix) so that they can then be hidden via linker scripts.
(cherry picked from commit c6610a216e)
Consistently apply this rule: the guard name is obtained from the
filename by stripping the leading "lib", converting '/' and '.' to
'_' and uppercasing the resulting name. Guard names in the root
directory have to be prefixed by "FFMPEG_".
Originally committed as revision 15120 to svn://svn.ffmpeg.org/ffmpeg/trunk