- 14 Jun, 2017 1 commit
-
-
Mark Thompson authored
(cherry picked from commit 64a5260c)
-
- 11 Jun, 2017 2 commits
-
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
- 16 May, 2017 1 commit
-
-
Rostislav Pehlivanov authored
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
-
- 12 May, 2017 1 commit
-
-
Michael Niedermayer authored
Fixes: 1293/clusterfuzz-testcase-minimized-6054752074858496 See: [FFmpeg-devel] [PATCH] avcodec/avcodec: Limit the number of side data elements per packet Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 23 Apr, 2017 1 commit
-
-
James Almer authored
This reverts commit bfdca87a. Packets with no data or side data will be valid EOF signal in an upcoming merge. Signed-off-by: James Almer <jamrial@gmail.com>
-
- 18 Apr, 2017 2 commits
-
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
- 06 Apr, 2017 2 commits
-
-
James Almer authored
-
Steve Lhomme authored
These data are necessary when transmitting HDR over HDMI. Signed-off-by: James Almer <jamrial@gmail.com>
-
- 05 Apr, 2017 1 commit
-
-
Damien Riegel authored
Add a codec capable of decoding some formats of the RFC4175. For now it's only capable of handling YCbCr-4:2:2 with 8-bit or 10-bit depth. For 8-bit it's a simple pass-through, for 10-bit it depacks the stream in the AV_PIX_FMT_YUV422P10 pixel format. Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com> Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
-
- 04 Apr, 2017 1 commit
-
-
Clément Bœsch authored
-
- 03 Apr, 2017 1 commit
-
-
Ronald S. Bultje authored
Fixes tsan warnings in several audio codecs (flac, alac, wavpack, tta and tak) that look like this: WARNING: ThreadSanitizer: data race (pid=14340) Read of size 4 at 0x7d64000169d8 by main thread (mutexes: write M1335): #0 update_context_from_thread src/libavcodec/pthread_frame.c:284 (ffmpeg+0x000000dc795f) [..] Previous write of size 4 at 0x7d64000169d8 by thread T1 (mutexes: write M1333): #0 wavpack_decode_block src/libavcodec/wavpack.c:1012 (ffmpeg+0x00000112b175)
-
- 29 Mar, 2017 1 commit
-
-
Clément Bœsch authored
-
- 26 Mar, 2017 1 commit
-
-
Michael Niedermayer authored
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 23 Mar, 2017 1 commit
-
-
wm4 authored
This "reuses" the flags introduced for the av_vdpau_bind_context() API function, and makes them available to all hwaccels. This does not affect the current vdpau API, as av_vdpau_bind_context() should obviously override the AVCodecContext.hwaccel_flags flags for the sake of compatibility. Cherry-picked from Libav commit 16a163b5. Reviewed-by: Mark Thompson <sw@jkqxz.net>
-
- 21 Mar, 2017 3 commits
-
-
Marton Balint authored
Reviewed-by: wm4 <nfxjfg@googlemail.com> Signed-off-by: Marton Balint <cus@passwd.hu>
-
Anton Khirnov authored
Certain hardware decoding APIs are not guaranteed to be thread-safe, so having the user access decoded hardware surfaces while the decoder is running in another thread can cause failures (this is mainly known to happen with DXVA2). For such hwaccels, only allow the decoding thread to run while the user is inside a lavc decode call (avcodec_send_packet/receive_frame). Merges Libav commit d4a91e65. Signed-off-by: wm4 <nfxjfg@googlemail.com> Tested-by: Michael Niedermayer <michael@niedermayer.cc>
-
wm4 authored
This patch deprecates anything that has to do with merging/splitting side data. Automatic side data merging (and splitting), as well as all API symbols involved in it, are removed completely. Two FF_API_ defines are dedicated to deprecating API symbols related to this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates AVFMT_FLAG_KEEP_SIDE_DATA in libavformat. Since it was claimed that changing the default from merging side data to not doing it is an ABI change, there are two additional FF_API_ defines, which stop using the side data merging/splitting by default (and remove any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec, and FF_API_LAVF_MERGE_SD in libavformat. It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD are quickly defined to 0 in the next ABI bump, while the API symbols are retained for a longer time for the sake of compatibility. AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for most of the time it will still be defined. Keep in mind that no code exists that actually tries to unset this flag for any reason, nor does such code need to exist. Code setting this flag explicitly will work as before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once side data merging has been removed from libavformat. In order to avoid that anyone in the future does this incorrectly, here is a small guide how to update the internal code on bumps: - next ABI bump (probably soon): - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it - define FF_API_MERGE_SD to 0, and remove all code covered by it - next API bump (typically two years in the future or so): - define FF_API_LAVF_KEEPSIDE_FLAG to 0, and remove all code covered by it - define FF_API_MERGE_SD_API to 0, and remove all code covered by it This forces anyone who actually wants packet side data to temporarily use deprecated API to get it all. If you ask me, this is batshit fucked up crazy, but it's how we roll. Making AVFMT_FLAG_KEEP_SIDE_DATA to be set by default was rejected as an ABI change, so I'm going all the way to get rid of this once and for all. Reviewed-by: James Almer <jamrial@gmail.com> Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 17 Mar, 2017 1 commit
-
-
Carl Eugen Hoyos authored
Fixes a gcc warning: libavcodec/bitstream_filter.c:71:20: warning: assignment discards 'const' qualifier from pointer target type
-
- 16 Mar, 2017 1 commit
-
-
Carl Eugen Hoyos authored
Reflects the actual code and silences a gcc warning: libavcodec/utils.c:2102:36: warning: passing argument 1 of 'av_packet_get_side_data' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
-
- 12 Mar, 2017 1 commit
-
-
Paras Chadha authored
Signed-off-by: Paras Chadha <paraschadha18@gmail.com>
-
- 09 Mar, 2017 1 commit
-
-
wm4 authored
Make it clear that there is no timing-dependent behavior. In particular, there is no state in which both input and output are denied, and where you have to wait for a while yourself to make progress (apparently some hardware decoders like to do this). Avoid wording that makes references to time. It shouldn't be mistaken for some kind of asynchronous API (like POSIX read() can return EAGAIN if there is no new input yet). It's a state machine, so try to use appropriate terms. Signed-off-by: Diego Biurrun <diego@biurrun.de> Merges Libav commit 8a60bba0.
-
- 02 Mar, 2017 2 commits
-
-
Kostya Shishkov authored
Only I-frames are decoded for now. Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
wm4 authored
Allow all struct fields to be accessed directly, as long as they're public. Before this change, many fields were "public", but could be accessed via AVOption only. This meant they were effectively not public, but were present for documentation purposes, which was incredibly confusing at best.
-
- 22 Feb, 2017 1 commit
-
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
- 13 Feb, 2017 1 commit
-
-
Mark Thompson authored
For use by codec implementations which can allocate frames internally.
-
- 12 Feb, 2017 1 commit
-
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
- 11 Feb, 2017 1 commit
-
-
Paul B Mahol authored
Only lossy part is decoded for now. Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
- 19 Jan, 2017 1 commit
-
-
Aleksandr Slobodeniuk authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 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.
-
- 11 Jan, 2017 1 commit
-
-
Steinar H. Gunderson authored
This decoder can decode all existing SpeedHQ formats (SHQ0–5, 7, and 9), including correct decoding of the alpha channel. 1080p is decoded in 142 fps on one core of my i7-4600U (2.1 GHz Haswell), about evenly split between bitstream reader and IDCT. There is currently no attempt at slice or frame threading, even though the format trivially supports both. NewTek very helpfully provided a full set of SHQ samples, as well as source code for an SHQ2 encoder (not included) and assistance with understanding some details of the format.
-
- 22 Dec, 2016 2 commits
-
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
Paul B Mahol authored
Signed-off-by: Paul B Mahol <onemda@gmail.com>
-
- 19 Dec, 2016 1 commit
-
-
Anton Khirnov authored
Certain hardware decoding APIs are not guaranteed to be thread-safe, so having the user access decoded hardware surfaces while the decoder is running in another thread can cause failures (this is mainly known to happen with DXVA2). For such hwaccels, only allow the decoding thread to run while the user is inside a lavc decode call (avcodec_send_packet/receive_frame).
-
- 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.
-
Martin Vignali authored
Decode the Image Data Section (which contains merged pictures). Support RGB/A and Grayscale/A in 8bits and 16 bits per channel. Support uncompress and rle decompression in Image Data Section. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 10 Dec, 2016 1 commit
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 07 Dec, 2016 1 commit
-
-
Vittorio Giovara authored
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-