| Age | Commit message (Collapse) | Author |
|---|
|
This removes the dependency that hardware pixel formats previously had on
AVHWAccel instances, meaning only those which actually do something need
exist after this patch.
Also updates avcodec_default_get_format() to be able to choose hardware
formats if either a matching device has been supplied or no additional
external configuration is required, and avcodec_get_hw_frames_parameters()
to use the hardware config rather than searching the old hwaccel list.
The FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS mechanism is deleted because it
no longer does anything (the codec already contains the pointers to the
matching hwaccels).
|
|
Also makes it more robust than using volatiles.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
|
|
* commit '3152058bf1dca318898550efacf0286f4836cae6':
libavcodec: Don't use dllexport, only dllimport when building DLLs
Merged-by: James Almer <jamrial@gmail.com>
|
|
The only purpose of dllexport (which is set while building the library
that exports the symbols) is to have the linker automatically
export such symbols into a DLL without using a def file - it doesn't
affect the generated code.
For both MSVC and mingw builds, this isn't essential since we override
what symbols to export via an autogenerated def file instead.
Update a comment in configure to refer to the right concept.
With lld, this avoids warnings about duplicate export directives,
when some symbols are requested to be exported both via dllexport
attributes and via the autogenerated def file.
This also reduces the number of lines of code marginally.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
* commit 'accb06120c13a4ead442464d96f2fa318fa07a4e':
configure: Use dllexport/dllimport for data symbols across DLLs with mingw
Merged-by: James Almer <jamrial@gmail.com>
|
|
* commit 'abf1c058d1bd0ed1b820ea5e501a4484756f00b0':
msvc: Properly specify dllexport for data symbols shared across dll boundaries
Merged-by: James Almer <jamrial@gmail.com>
|
|
Currently, AVHWAccels are looked up using a (codec_id, pixfmt) tuple.
This means it's impossible to have 2 decoders for the same codec and
using the same opaque hardware pixel format.
This breaks merging Libav's CUVID hwaccel. FFmpeg has its own CUVID
support, but it's a full stream decoder, using NVIDIA's codec parser.
The Libav one is a true hwaccel, which is based on the builtin software
decoders.
Fix this by introducing another field to disambiguate AVHWAccels, and
use it for our CUVID decoders. FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS makes
this mechanism backwards compatible and optional.
|
|
* commit '94eed68ace9f2416af8457fcbf142b175928c06b':
lavc: Drop deprecated options moved to private contexts
Merged-by: James Almer <jamrial@gmail.com>
|
|
* commit 'cbebc3251bc2544b469e0dcb176bc04779d8866c':
lavc: Drop deprecated public symbols
Merged-by: James Almer <jamrial@gmail.com>
|
|
The actual API is left in place until the deprecation period ends.
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
Signed-off-by: Ilia Valiakhmetov <zakne0ne@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
Their use in the public header is deprecated and will be removed, but
they are still needed by some codecs at least as long as qscale related
deprecated fields in the AVFrame struct remain in the tree.
|
|
This avoids having to use pseudo relocations.
The version script used for exporting functions is skipped as soon
as the set of object files contains symbols marked with dllexport,
therefore we need to use makedef to produce the full list of symbols
to be exported.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
We currently only have exported data symbols within libavcodec, but
the concept is easy to extend to other libraries if necessary.
The attribute declaration needs to be in a private header though,
since we can't use CONFIG_SHARED in public installed headers.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
* commit '019ab88a95cb31b698506d90e8ce56695a7f1cc5':
lavc: add an option for exporting cropping information to the caller
Merged-by: James Almer <jamrial@gmail.com>
|
|
Fixes Timeout
Fixes: 508/clusterfuzz-testcase-6245747678773248
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
The code it refers to was moved to decode.c in 00fb745a10a151791ce2e49ba3e463bd17ea9251
|
|
So, all frames and errors are correctly reported in order.
Also limit the numbers of error during draining to prevent infinite loop.
This fix fate failure with THREADS>=4:
make fate-h264-attachment-631 THREADS=4
This also reverts a755b725ec1d657609c8bd726ce37e7cf193d03f.
Suggested-by: wm4, Ronald S. Bultje, Marton Balint
Reviewed-by: w4 <nfxjfg@googlemail.com>
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
|
|
* commit '972c71e9cb63e24f57ee481e413199c7d88a8813':
lavc: add support for filtering packets before decoding
Merged-by: James Almer <jamrial@gmail.com>
|
|
* commit '061a0c14bb5767bca72e3a7227ca400de439ba09':
decode: restructure the core decoding code
CUVID decoder adapted by wm4.
Merged-by: James Almer <jamrial@gmail.com>
|
|
* commit '549d0bdca53af7a6e0c612ab4b03baecf3a5878f':
decode: be more explicit about storing the last packet properties
Also copy pkt->size in extract_packet_props(), as it's needed for
AVFrame.pkt_size
Merged-by: James Almer <jamrial@gmail.com>
|
|
Deprecated in 10/2014 and 07/2015.
|
|
Allows to get a more realistic total bitrate (and estimated file size)
in avi_write_header. Previously a static default value of 200k was
assumed.
Adds an internal helper function for bitrate guessing.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
Fixes a gcc warning:
libavcodec/utils.c:2244:26: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
|
|
* commit '89aebc5bcc6e23a0a79c3f51c3a55c3571692ba0':
lavc: align the linesize to 32 when AVX is enabled
Merged-by: James Almer <jamrial@gmail.com>
|
|
Apparently the demuxer outputs the wrong padding for HE-AAC (based on
the raw sample rate, or so). aacdec contains a hack to adjust the muxer
padding accordingly before it's used to trim the decoder output. This
modified the packet side data, which in combination with the old
decoding API would change the packet the user passed to the decoder.
This is clearly not allowed, and it breaks running some gapless fate
tests with "-fflags +keepside" applied (without keepside, the packet
metadata is typically newly allocated, essentially making a copy and not
modifying the user's input packet).
This should probably be fixed in the demuxer (and consequently also the
muxer), but for now only fix the immediate problem.
Regression since 946ed78f5f8 (2012).
|
|
Also, add generic code for handling cropping, so the decoders can export
just the cropping size and not bother with the rest.
|
|
|
|
Currently, the new decoding API is pretty much just a wrapper around the
old deprecated one. This is problematic, since it interferes with making
full use of the flexibility added by the new API. The old API should
also be removed at some future point.
Reorganize the code so that the new send_packet/receive_frame functions
call the actual decoding directly and change the old deprecated
avcodec_decode_* functions into wrappers around the new API.
The new internal API for decoders is now changing as well. Before this
commit, it mirrors the public API, so the decoders need to implement
send_packet() and receive_frame() callbacks. This turns out to require
awkward constructs in both the decoders and the generic code. After this
commit, the decoders only implement the receive_frame() callback and
call a new internal function, ff_decode_get_packet() to obtain input
data, in the same manner to how the bitstream filters now work.
avcodec will now always make a reference to the input packet, which means
that non-refcounted input packets will be copied. Keeping the previous
behaviour, where this copy could sometimes be avoided, would make the
code significantly more complex and fragile for only dubious gains,
since packets are typically small and everyone who cares about
performance should use refcounted packets anyway.
|
|
The current code stores a pointer to the packet passed to the decoder,
which is then used during get_buffer() for timestamps and side data
passthrough. However, since this is a pointer to user data which we do
not own, storing it is potentially dangerous. It is also ill defined for
the new decoding API with split input/output.
Fix this problem by making an explicit internally owned copy of the
packet properties.
|
|
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
With the new decode API, doing this in ffmpeg.c is impractical. There
was resistance against removing the warning, so put it into libavcodec.
Not bothering with reducing the warning to verbose log level for
subsequent wanrings. The warning should be rare, and only happen when
developing new codecs for the old API.
Includes a change suggested by Michael Niedermayer.
|
|
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.
This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the packet and may produce output, the new API requires the user
to send input first, and then ask for output.
For now, there are no codecs supporting this API. The API can work with
codecs using the old API, and most code added here is to make them
interoperate. The reverse is not possible, although for audio it might.
From Libav commit 05f66706d182eb0c36af54d72614bf4c33e957a9.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
With this the use of the caps_internal from libavformat can be avoided
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.
This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the packet and may produce output, the new API requires the user
to send input first, and then ask for output.
For now, there are no codecs supporting this API. The API can work with
codecs using the old API, and most code added here is to make them
interoperate. The reverse is not possible, although for audio it might.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
|
* commit '34138ece23c8ddae543269212a051c00d49e67d7':
log: Use a do {} while (0) for tlog
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
|
* commit '11c9bd633f635f07a762be1ecd672de55daf4edc':
libopenh264enc: export CPB props side data
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
|
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
|
|
Avoid the warning `-Wempty-body`.
|
|
|
|
Avoid the warning `-Wempty-body`.
|
|
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
The decoder extracts and fills its parameters even if the frame is
skipped due to the skip_frame setting.
|
|
It is only used inside libavcodec.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
|
|
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
Avoids problems when used without braces
Found-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
This silences a -Wempty-body warning on clang 3.7+, e.g
http://fate.ffmpeg.org/log.cgi?time=20150918181527&log=compile&slot=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
The generic code in utils.c sets the AVFrame.pkt_dts field from the
packet it was supposedly decoded. This does not have to be true for a
fully asynchronous decoder like mmaldec. It could be overwritten with an
incorrect value. Even if the decoder doesn't determine the DTS (but sets
it to AV_NOPTS_VALUE), it's impossible to determine a correct value in
utils.c.
Decoders can now be marked with FF_CODEC_CAP_SETS_PKT_DTS, in which case
utils.c won't overwrite the field. The decoders are expected to set this
field (even if they only set it to AV_NOPTS_VALUE).
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
* commit '87a051f97633010f71dfc1d23d806856499bf231':
lavc: allow asynchronous decoders to return correct pkt_dts values
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
|
