- 02 Jun, 2020 1 commit
-
-
James Almer authored
Signed-off-by: James Almer <jamrial@gmail.com>
-
- 01 Jun, 2020 1 commit
-
-
Andreas Rheinhardt authored
It is no longer used anymore. Reviewed-by: James Almer <jamrial@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
- 10 May, 2020 1 commit
-
-
James Almer authored
Signed-off-by: James Almer <jamrial@gmail.com>
-
- 02 May, 2020 1 commit
-
-
Marton Balint authored
Signed-off-by: Marton Balint <cus@passwd.hu>
-
- 10 Apr, 2020 2 commits
-
-
Anton Khirnov authored
Currently the frame pool used by the default get_buffer2() implementation is a single struct, allocated when opening the decoder. A pointer to it is simply copied to each frame thread and we assume that no thread attempts to modify it at an unexpected time. This is rather fragile and potentially dangerous. With this commit, the frame pool is made refcounted, with the reference being propagated across threads along with other context variables. The frame pool is now also immutable - when the stream parameters change we drop the old reference and create a new one.
-
Anton Khirnov authored
This is a constant codec property, so a capability flag is more appropriate.
-
- 04 Feb, 2020 1 commit
-
-
Michael Kuron authored
Signed-off-by: Michael Kuron <michael.kuron@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 22 Jan, 2020 1 commit
-
-
Michael Niedermayer authored
This allows the fuzzer to target meaningfull codec tags instead of hunting the 4gb space, which it seems to have problems with. Suggested-by: James Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 16 Jan, 2020 1 commit
-
-
James Almer authored
Signed-off-by: James Almer <jamrial@gmail.com>
-
- 04 Sep, 2019 1 commit
-
-
James Almer authored
Some decoders may not need a writable buffer in some specific cases, but only a reference to the existing buffer with updated frame properties instead, for the purpose of returning duplicate frames. For this, the FF_REGET_BUFFER_FLAG_READONLY flag is added, which will prevent potential allocations and buffer copies when they are not needed. Signed-off-by: James Almer <jamrial@gmail.com>
-
- 20 Aug, 2019 1 commit
-
-
Michael Niedermayer authored
This allows decoding more als reference samples Suggested-by: Thilo Borgmann <thilo.borgmann@mail.de> Reviewed-by: Thilo Borgmann <thilo.borgmann@mail.de> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 20 Apr, 2019 1 commit
-
-
Gyan Doshi authored
Discard decoded frames which differ from first decoded frame in stream.
-
- 04 Dec, 2018 1 commit
-
-
Martin Vignali authored
to check valid value, or return default_value
-
- 13 Jul, 2018 1 commit
-
-
Marton Balint authored
This was reduced from 128 in libav commit 192f1984, but since we support unknown channel layouts, we can increase this limit. Fixes ticket #6332. Signed-off-by: Marton Balint <cus@passwd.hu>
-
- 14 Feb, 2018 1 commit
-
-
James Almer authored
And remove the function altogether while at it. It's a duplicate of another. Reviewed-by: wm4 <nfxjfg@googlemail.com> Signed-off-by: James Almer <jamrial@gmail.com>
-
- 26 Dec, 2017 2 commits
-
-
wm4 authored
This is just a lot of complicated and confusing code that had no purpose anymore. Also, the functions return values were checked only sometimes. Locking shouldn't fail anyway, so remove the return values. Barely any other pthread lock calls check the return value (including more important code that is more likely to fail horribly if locking fails). It could be argued that it might be helpful in some debugging situations, or when the user built FFmpeg without thread support against all good advice. But there are dummy atomics too, so the atomic check won't help with ensuring correctness absolutely. You gain very little. Also, for debugging, you can just raise the ASSERT_LEVEL, and then libavutil/thread.h will redefine the locking functions to explicitly check the return values.
-
wm4 authored
It's completely absurd that libavcodec would care about libavformat locking, but it was there because the lock manager was in libavcodec. This is more stright forward. Changes ABI, but we don't require ABI compatibility currently.
-
- 24 Dec, 2017 1 commit
-
-
James Darnley authored
-
- 19 Dec, 2017 1 commit
-
-
Mark Thompson authored
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.
-
- 11 Dec, 2017 1 commit
-
-
Hendrik Leppkes authored
This reverts commit 590136e7. Atomics are not required for this variable, because it is protected through the lock manager, and the use of atomics here is not compatible with the c11 emulation wrappersi. Fixes FATE on MSVC, among other setups which use the compat wrappers.
-
- 26 Nov, 2017 2 commits
-
-
Mark Thompson authored
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).
-
Rostislav Pehlivanov authored
Also makes it more robust than using volatiles. Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
-
- 19 Nov, 2017 1 commit
-
-
Martin Storsjö authored
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>
-
- 10 Nov, 2017 1 commit
-
-
wm4 authored
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.
-
- 22 Oct, 2017 1 commit
-
-
James Almer authored
The actual API is left in place until the deprecation period ends. Signed-off-by: James Almer <jamrial@gmail.com>
-
- 08 Sep, 2017 1 commit
-
-
Ilia Valiakhmetov authored
Signed-off-by: Ilia Valiakhmetov <zakne0ne@gmail.com> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
-
- 01 Sep, 2017 1 commit
-
-
James Almer authored
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.
-
- 31 Aug, 2017 2 commits
-
-
Martin Storsjö authored
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>
-
Martin Storsjö authored
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>
-
- 06 May, 2017 1 commit
-
-
Michael Niedermayer authored
Fixes Timeout Fixes: 508/clusterfuzz-testcase-6245747678773248 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 01 May, 2017 1 commit
-
-
James Almer authored
The code it refers to was moved to decode.c in 00fb745a
-
- 29 Apr, 2017 1 commit
-
-
Muhammad Faiz authored
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 a755b725. 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>
-
- 23 Mar, 2017 1 commit
-
-
Vittorio Giovara authored
Deprecated in 10/2014 and 07/2015.
-
- 17 Mar, 2017 1 commit
-
-
Tobias Rapp authored
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>
-
- 16 Mar, 2017 1 commit
-
-
Carl Eugen Hoyos authored
Fixes a gcc warning: libavcodec/utils.c:2244:26: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
-
- 09 Mar, 2017 1 commit
-
-
wm4 authored
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 946ed78f (2012).
-
- 12 Jan, 2017 1 commit
-
-
Anton Khirnov authored
Also, add generic code for handling cropping, so the decoders can export just the cropping size and not bother with the rest.
-
- 14 Dec, 2016 3 commits
-
-
Anton Khirnov authored
-
Anton Khirnov authored
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.
-
Anton Khirnov authored
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.
-