No global variables are used and the VLC tables are allocated without
static elements. This will allow using a JPEG decoding context within
other decoders.
This field is designed for marking codec properties useful to lavc internals.
Two internal capabilities are added:
- FF_CODEC_CAP_INIT_THREADSAFE: codec can be opened without locks;
- FF_CODEC_CAP_INIT_CLEANUP: codec frees memory if initialization fails.
The main difference consists in renaming properly labels, and
letting yasm select the gprs for skipping 1D transforms.
Previous-version-reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '78c892284150e12f6b08b287bdf7e62307c6985f':
dca: Document the permuted order in the lfe_fir_64 and lfe_fir_128 tables
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '212556cd2144659dc6b9d121ddb38cd272bd10ae':
qsv: Improve the log message of when initializing MFX_IMPL_HARDWARE{2, 3, 4}
Merged-by: Michael Niedermayer <michaelni@gmx.at>
So far it is only set in roq_encode_frame, but it is used in
roq_encode_end to free the coded_frame. This currently segfaults if
roq_encode_frame is not called between roq_encode_init and
roq_encode_end.
CC:libav-stable@libav.org
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Also moves the shift out of the inner loop
Found-by: Clang -fsanitize=shift
Reported-by: Thierry Foucu <tfoucu@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This also simplifies the code
Found-by: Clang -fsanitize=shift
Reported-by: Thierry Foucu <tfoucu@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The fourth substream is being discarded, since its not raw audio data,
but an encoded Atmos stream which needs a specialized decoder.
Fixes decoding of the true hd stream from Transformers\ -\ Age\ of\ Extinction\ 2014\ 1080P-003.mkv
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Fixes out of array accesses
Fixes: ffmpeg_012v_crash.ts
Found-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Reviewed-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
So far it is only set in roq_encode_frame, but it is used in
roq_encode_end to free the coded_frame. This currently segfaults if
roq_encode_frame is not called between roq_encode_init and
roq_encode_end.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '93f7948136fcda8ddbbc44a6c24418f11ca829b8':
libvpx: Fix mixed use of av_malloc() and av_reallocp()
Merged-by: Michael Niedermayer <michaelni@gmx.at>
allowing access to the size but not the extradata itself is not useful
and could lead to potential problems if writing happens through this field
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Reviewed-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This buffer is resized when vpx_codec_get_cx_data() returns a
VPX_CODEC_STATS_PKT packet.
CC: libav-stable@libav.org
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit 'ae5e1f3d663a8c9a532d89e588cbc61f171c9186':
tiff: Check that there is no aliasing in pixel format selection
See: e1c0cfaa41
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '0025f7408a0fab2cab4a950064e4784a67463994':
vorbis: Check the vlc value in setup_classifs
Conflicts:
libavcodec/vorbisdec.c
See: ae038c0914
See: 709cae2bcb
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The valid returned values are always at most 11bit.
Remove the previous check that assumed larger values plausible and
use a signed integer to check get_vlc2 return values.
CC: libav-stable@libav.org
Fixes out of array access
Fixes: ffmpeg_opus_crash1.ogg
This solution is likely not optimal in terms of error concealment but
its simple and fixes the out of array access.
Found-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is safer than to assume that all error pathes cleared them and
nothing will use uncleared pointers.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes out of array accesses
Fixes: ffmpeg_mjpeg_crash2.avi
Found-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This mainly consists of replacing all the pointer arithmatic 'addiu'
instructions with PTR_ADDIU which will handle the differences in pointer
sizes when compiled on 64 bit mips systems.
The header asmdefs.h contains the PTR_ macros which expend to the correct mips
instructions to manipulate registers containing pointers.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Reviewed-by: Nedeljko Babic <Nedeljko.Babic@imgtec.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
There are no independant uses of mips32r2 instructions except for the
FPU parts. Due to the heavy use of mips32r2 specifc fpu extensions, I
am guessing the original author intended MIPSFPU to imply MIPS32R2 anyway.
Since these fpu instructions are available on mips64 (non-r2), enable them
there as well.
Also remove the last occurence of HAVE_MIPS32R2 (which is coupled to
HAVE_MIPSFPU anyway).
mips32r2 is left in the list of options form compatability so that using
--disable-mips32r2 doesn't break anything.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Removing these removes the dependency of this code on mips32r2 which would
allow it to be used on processors which have FPU instructions, but not r2
instructions (like the mips64el debian port for instance).
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Reviewed-by: Nedeljko Babic <Nedeljko.Babic@imgtec.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Instead, warn that bitrate will be clamped down to the maximum allowed.
Patch is mostly work of Kamendo2 in issue #2686, quite tested within that issue.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '25c29d32835f38cdc5f0c84fa27dfc489a228770':
libopenh264enc: Add support for building with OpenH264 1.4
Merged-by: Michael Niedermayer <michaelni@gmx.at>
According to the WebP Lossless Bitstream Specification
"each transform is allowed to be used only once".
If a transform is more than once this can lead to memory
corruption.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If it doesn't fit into 12 bits it triggers an assertion.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
According to the WebP Lossless Bitstream Specification the highest
allowed value for a prefix code is 39.
If prefix_code is too large, the calculated extra_bits has an invalid
value and triggers an assertion in get_bits.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Regular autovariance is no longer "experimental", and a version of it with
bias towards dark scenes is now in mainline x264.
Signed-off-by: Peter Cordes <peter@cordes.ca>
* commit '25f613f8be3b51e4396b93cda131e4631ba54302':
dca: Move syncword definitions to a separate header
Conflicts:
libavcodec/dca_parser.c
libavformat/dtsdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Although the specification mandates this bit to zero, it may happen
that software tools incorrectly flip it to one, invalidating a possibly
valid stream.
Relax this restriction, by failing only when AV_EF_BITSTREAM is set.
This behaviour is similar to aac decoders in Firefox and Quicktime.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The macro is implemented as a do{}while()
enclosing this is () appears to be a GNU extension (6.1 Statements and Declarations in Expressions)
the () is also unneeded and wrong as the macro returns no
value
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes pixel values not being properly shifted in
libopenjpeg_copyto16 and libopenjpeg_copy_to_packed16 methods.
Pixel formats like xyz12le need to be shifted by AVComponentDescriptor::shift
to get the correct values.
Reviewed-by: Michael Bradshaw <mjbshaw@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
On mips64, the registers t[4-7] do not exist. Instead of using a lot of #ifdef
or defines to handle differing register names, use variables and let GCC
allocate the registers automatically (like in the other mips assembly files).
In get_band_cost_ESC_mips, t4 and t5 were renamed to t6 and t7 to avoid a
variable name conflict.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Reviewed-by: Nedeljko Babic <Nedeljko.Babic@imgtec.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is obviously needed for 64-bit support.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Reviewed-by: Nedeljko Babic <Nedeljko.Babic@imgtec.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Normally the aic decoder finds the proper slice combination (multiple of
some number less than 32) but in case of odd width, it resorts to the
default values, which were actually swapped.
The number of slices is modified to account for such odd width cases.
CC: libav-stable@libav.org
This patch fixes a pointer arithmetic bug in adjust_frame_information that resulted in heavily corrupted audio when using M/S encoding. Also, a backup copy of untransformed coefficients has to be kept around or attempts at re-processing the frame (which happens when hevavily overspending bits during transients) will result in re-encoding of the coefficients and subsequent corruption of the resulting stream.
A/B testing shows the bug as corrected, but still cannot prove that M/S coding is a win at least in numbers. Limited listening tests do show improvement on M/S encoded samples in lower bitrates, but they're hidden among the other artifacts that remain to be corrected in the encoder.
Some of the regressions flagged in the report do show poor stereo image (but not buggy), so M/S encoding is clearly not good enough yet to be defaulted to auto.
In numbers, Patched against Unpatched, stereo_mode auto:
Files: 114
Bitrates: 6
Tests: 683
Serious Regressions: 0 (0%)
Regressions: 0 (0%)
Improvements: 227 (33%)
Big improvements: 92 (13%)
Worst regression - mybloodrusts.wv - 256k
- StdDev: 28.61 pSNR: -0.43 maxdiff: 1372.00
Best improvement - 60.wv - 384k
- StdDev: -369.57 pSNR: 45.02 maxdiff: -13322.00
Average - StdDev: -80.56 pSNR: 2.49 maxdiff: -8858.00
Patched against Unpatched stereo_mode ms_off shows no difference.
Patched stereo_mode auto vs Unpatched stereo_mode ms_off shows a small average improvement, just not too significant:
Serious Regressions: 0 (0%)
Regressions: 10 (1%)
Improvements: 45 (6%)
Big improvements: 2 (0%)
Worst regression - Illinois.wv - 256k
- StdDev: 33.20 pSNR: -2.03 maxdiff: 477.00
Best improvement - song_of_circomstances.flac - 384k
- StdDev: -3.97 pSNR: 7.61 maxdiff: -826.00
Average - StdDev: -10.25 pSNR: 0.20 maxdiff: -281.00
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If it doesn't fit into 12 bits it triggers an assertion.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
According to the WebP Lossless Bitstream Specification the highest
allowed value for a prefix code is 39.
If prefix_code is too large, the calculated extra_bits has an invalid
value and triggers an assertion in get_bits.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is a small change, but it does have a big impact on bit allocation.
all the regressions marked in the report have no audible
difference (I didn't check them all though), but the improvements can
be heard.
This affects mostly high bit rates. It's related to issue #2686.
In the report, A is the patched version, B is unpatched, all
comparisons show deltas in the form (A-B), so a positive pSNR delta
means a better quality in the patched version, and negative a
regression. Regressions are only considered for pSNR deltas below
-1db, they're considered serious below -6db.
All measurements were done with tiny_psnr.
The summary of the report inline for quick reading:
Files: 58
Bitrates: 6
Tests: 347
Serious Regressions: 0 (0%)
Regressions: 10 (2%)
Improvements: 54 (15%)
Big improvements: 26 (7%)
Worst regression - sine_tester.flac - 384k
- StdDev: 1.68 pSNR: -3.05 maxdiff: -178.00
Best improvement - 07 - Bound.flac - 384k
- StdDev: -1700.05 pSNR: 20.64 maxdiff: -29595.00
Average - StdDev: -55.67 pSNR: 1.20 maxdiff: -1593.00
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Some files produced by the official encoder have up to 16bit of
padding instead of the expected padding to the byte.
Use a self-explanatory macro instead of a simple number.
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
9127 -> 8936 decicycles (fate-suite/vc1/SA10143.vc1)
13855 -> 10976 decicycles (fate-suite/vc1/SA20021.vc1)
tests done by the author over this function but with the whole
patchset applied not just this commit
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Several encoders were multiplying the buffer size by 8, in order to get
a bit size. However, the buffer_size argument is for the byte size of
the buffer. We had experienced crashes encoding prores (Anatoliy) at
size 4096x4096.
Change register constraint on the v variable from = to +. This was causing GCC
to think that the v variable was never read and therefore not initialize it.
This fixes about 20 fate failures on mips64el.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The float_copy and fmul_and_reverse functions are refactored out from the
multiple copies in this file.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The optimized C version of this code actually runs faster than this
version, so remove it.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Remove some assembly that the compiler can easily handle optimally on its own.
GCC produces almost identical assembly.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Q_fract should have be declared as 'const float*'.
Also fix the constness of some local variables affected by this.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
GCC is perfectly happy generating optimized multiplication code on its own for
64-bit arches. GCC refuses to optimize the loongson code when in 32-bit mode,
so I've left that.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes out of array read
Fixes: asan_heap-oob_4d4eb0_3994_cov_3169972261_zmbv_15bit.avi
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes out of array read
Fixes: asan_heap-oob_2ff30d2_3479_cov_3803648058_src13_hrc7_525_420_2.264
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
When calling ff_alloc_entries, a number of entries are created.
They are never freed, as running fate with slice threading and
several frames on e.g. fate-hevc-conformance-ENTP_A_Qualcomm_1
would show.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes the following link error:
nutdec.c:(.text+0x2d47): undefined reference to `ff_codec_movvideo_tags'
isom.c:(.text+0x332): undefined reference to `avpriv_mpeg4audio_get_config'
isom.c:(.text+0x39e): undefined reference to `avpriv_mpa_freq_tab'
Fixes integer overflow and out of array read.
Fixes: signal_sigsegv_24169e6_3445_cov_3778346427_snow_chroma_bug.avi
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'cb4cb7b0ea12b791dde587b1acd504dbb4ec8f41':
qsv: Skip qsv.h compilation if qsv is not enabled
Conflicts:
libavcodec/Makefile
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '061c489895d29049a88dc6118e4b639a273b31d6':
eamad: check for out of bounds read
Conflicts:
libavcodec/eamad.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Averaging over 2 pixels doesn't work correctly for the last pixel, because the
rest of the buffer is not initialized.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes invalid reads of the packet buffer in av_dup_packet
Based on patch by Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Currently, a part of the loop has to be handled in plain C, because of DSP
function requirements of having batches of 16 elements to process.
Instead, pad the buffer with 0 where the DSP functions are overreading.
Signed-off-by: James Almer <jamrial@gmail.com>
Based on patch by Francisco Blas Izquierdo Riera
Commit message partly taken from carl
fixes a compilation
error in mlpdsp_init.c with -fstack-check and some gcc compilers (I
reproduced the issue with gcc 4.7.3) by simplifying the code.
See also https://bugs.gentoo.org/show_bug.cgi?id=471756
$ make libavcodec/x86/mlpdsp_init.o
libavcodec/x86/mlpdsp_init.c: In function ‘mlp_filter_channel_x86’:
libavcodec/x86/mlpdsp_init.c:142:5: error: can’t find a register in
class ‘GENERAL_REGS’ while reloading ‘asm’
libavcodec/x86/mlpdsp_init.c:142:5: error: ‘asm’ operand has impossible
constraints
4551 -> 4509 dezicycles
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '0dea4c77ccf5956561bb8991311b3d834bb5fa40':
h264: only ref cur_pic in update_thread_context if it is initialized
Conflicts:
libavcodec/h264_slice.c
See: 0fc01ae33c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9abc80f1ed673141326341e26a05c3e1f78576d0':
libavcodec: Make use of av_clip functions
Conflicts:
libavcodec/takdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Also check the combined_pitch for validity (which is needed to keep the behavior
identical in the error case)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '31d2039cb42668ebcf08248bc48bbad44aa05f49':
h264_parser: export video format and dimensions
Conflicts:
libavcodec/h264_parser.c
libavcodec/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The 3*stride value stored in r3src can be loaded much later,
so use r3src instead of a dedicated gpr when possible.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
GCC 4.9.2 on a Core i5-4200U @ 1.60GHz, Linux x86_64
Before
715487 decicycles in sao_edge_filter_8, 262144 runs, 0 skips
After
672104 decicycles in sao_edge_filter_8, 262144 runs, 0 skips
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '3a651f599a18b023602370b67a77eb0efa309b20':
dca: Move data tables from a header to an object file
Conflicts:
libavcodec/Makefile
libavcodec/dcadata.h
libavcodec/dcadec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '73ae0a9d12857852222363f9a7c14d07058ebfd3':
g722: Split out computation of band->s_zero and unroll code
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '10f160768b824f00933f33bc69f1fae89a25dfc8':
g722: Reduce number of pointers passed to g722_apply_qmf() function
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '67690683130faf37dd9d969ced15eba2a1940ade':
g722: Split out g722_qmf_apply() function into g722dsp.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This also allows replacing several literal numbers by named constants
And it should be faster, the function is not speed relevant though as it is
generally only called a few times at the streams start.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '2a9c6fae927964b5dd0b5d3d9292f5621bd21664':
dca: Move all tables into dcadata.h
Conflicts:
libavcodec/dcadec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b339019de4e5f4d3c661bbdba98ae248ab77e2f0':
dca: Split code for handling the EXSS extension off into a separate file
Conflicts:
libavcodec/Makefile
libavcodec/dcadec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The second stride is always the internal buffer one, MAX_PB_SIZE (times 2 to
get the value in bytes).
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
hevc seems to be the only place where the C implementation
of the av_clip function is explicitly selected, precluding
platform-specific optimizations
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Fixes out of array accesses
Fixes: ffmpeg_mjpeg_crash.avi
Found-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Also move EC ref initialization to where the EC code is called.
Fixes out of array read
Fixes: asan_heap-uaf_143f420_142_20110805_112659_ch0.mkv
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The width parameter is now completely at the back, and actually
never used. This helps understanding the actual parameter list.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Their intent was to make the DSP work with wmalossless pro.
The later was fixed to work with the DSP.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The scaling list can be specified in either the SPS or PPS.
Additionally, compensate for the diagonal scan permutation applied
in the decoder.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
pb_eo must be handled as a rip relative address for MSVC64, so an
intermediate register is needed. Should fix link failures.
Suggested by Hendrik Leppkes and Christophe Gisquet.
Tested-By: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Christophe Gisquet <christophe.gisquet@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The epel_hv functions were still relying on only epel_hv 8-wide
being the maximum width instanciated.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes out of array read
Fixes: asan_static-oob_30328b6_719_cov_3325483287_H264_artifacts_motion.h264
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit 3b4ffba3af.
Unbreaks the SSSE3 code on mingw32
Conflicts:
libavcodec/x86/lossless_audiodsp.asm
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is needed as the mmx code is used as fallback from the ssse3 code
Suggested-by: jamrial
Tested-by: wm4
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The buffer pointers would be otherwise overwritten, causing a
leak on e.g. PERSIST_RPARAM_A_RExt_Sony_1.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
All the webm/vp9 files I have seen so far can have packets that contain
1 invisible and 1 visible frame. The vp9 parser separates them. Since
the invisible frame is always (?) the first sub-packet, the new packet
is assigned the PTS of the original packet, while the packet containing
the visible frame has no PTS.
This patch essentially reassigns the PTS from the invisible to the
visible frame.
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Original x86 intrinsics code by Pierre-Edouard Lepere.
Yasm port, refactoring and optimizations by James Almer.
Benchmarks of BQTerrace_1920x1080_60_qp22.bin with an Intel Core i5-4200U
Width 32
342694 decicycles in sao_edge_filter_10, 16384 runs, 0 skips
29476 decicycles in ff_hevc_sao_edge_filter_32_10_ssse3, 16384 runs, 0 skips
13996 decicycles in ff_hevc_sao_edge_filter_32_10_avx2, 16381 runs, 3 skips
Width 64
581163 decicycles in sao_edge_filter_10, 8192 runs, 0 skips
59774 decicycles in ff_hevc_sao_edge_filter_64_10_ssse3, 8192 runs, 0 skips
28383 decicycles in ff_hevc_sao_edge_filter_64_10_avx2, 8191 runs, 1 skips
Signed-off-by: James Almer <jamrial@gmail.com>
Original x86 intrinsics code and initial yasm port by Pierre-Edouard Lepere.
Refactoring and optimizations by James Almer.
Benchmarks of BQTerrace_1920x1080_60_qp22.bin with an Intel Core i5-4200U
Width 32
158583 decicycles in edge, sao_edge_filter_8 runs, 0 skips
5205 decicycles in ff_hevc_sao_edge_filter_32_8_ssse3, 32767 runs, 1 skips
2942 decicycles in ff_hevc_sao_edge_filter_32_8_avx2, 32767 runs, 1 skips
Width 64
705639 decicycles in sao_edge_filter_8, 262144 runs, 0 skips
19224 decicycles in ff_hevc_sao_edge_filter_64_8_ssse3, 262111 runs, 33 skips
10433 decicycles in ff_hevc_sao_edge_filter_64_8_avx2, 262115 runs, 29 skips
Signed-off-by: James Almer <jamrial@gmail.com>
This ensures we do not loose the frame in case or multiple clears
Fixes out of array read
Fixes: asan_heap-oob_2fa47ea_2100_cov_1278768963_ff_add_pixels_clamped_mmx.m2ts
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
For reasons we are not privy to, nvidia decided that the nvenc encoder
should apply aspect ratio compensation to 'DVD like' content, assuming that
the content is not bt.601 compliant, but needs to be bt.601 compliant. In
this context, that means that they make the following, questionable,
assumptions:
1) If the input dimensions are 720x480 or 720x576, assume the content has
an active area of 704x480 or 704x576.
2) Assume that whatever the input sample aspect ratio is, it does not account
for the difference between 'physical' and 'active' dimensions.
From, these assumptions, they then conclude that they can 'help', by adjusting
the sample aspect ratio by a factor of 45/44. And indeed, if you wanted to
display only the 704 wide active area with the same aspect ratio as the full
720 wide image - this would be the correct adjustment factor, but what if you
don't? And more importantly, what if you're used to ffmpeg not making this kind
of adjustment at encode time - because none of the other encoders do this!
And, what if you had already accounted for bt.601 and your input had the
correct attributes? Well, it's going to apply the compensation anyway!
So, if you take some content, and feed it through nvenc repeatedly, it
will keep scaling the aspect ratio every time, stretching your video out
more and more and more.
So, clearly, regardless of whether you want to apply bt.601 aspect ratio
adjustments or not, this is not the way to do it. With any other ffmpeg
encoder, you would do it as part of defining your input paramters or
do the adjustment at playback time, and there's no reason by nvenc
should be any different.
This change adds some logic to undo the compensation that nvenc would
otherwise do.
nvidia engineers have told us that they will work to make this
compensation mechanism optional in a future release of the nvenc
SDK. At that point, we can adapt accordingly.
Signed-off-by: Philip Langdale <philipl@overt.org>
Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes integer overflow and out of array read
Fixes: asan_heap-oob_1fb2f9b_3780_cov_3984375136_usf.mkv
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
As with sao_band_filter, pass instead the two variables from the struct needed in the function.
This simplifies writing asm optimized versions.
Reviewed-by: Mickaël Raulet <mraulet@insa-rennes.fr>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes out of array accesses
Fixes: asan_heap-oob_1c1a4ea_1242_cov_2274415971_TESTcmyk.jpg
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The scaling list can be specified in either the SPS or PPS.
Additionally, compensate for the diagonal scan permutation applied in the decoder.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'd615187f74ddf3413778a8b5b7ae17255b0df88e':
aacdec: Support for ER AAC ELD 480.
Conflicts:
libavcodec/aacdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '0ee2573347ecdb9cb5656001f7201d819eec16d8':
aacdec: Support for ER AAC in LATM
Conflicts:
libavcodec/aacdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Some files contain a few additional, all-0 bits.
Check for that case and don't print incorrect "not supported"
message.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Alex Converse <alex.converse@gmail.com>
Use edge emu buffers
And enable the code unconditionally
Speed difference without USE_SAO_SMALL_BUFFER and with the new code:
Decicycles: 26772->26220 (BO32), 83803->80942 (BO64)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
cherry picked from commit 5d9f79edef2c11b915bdac3a025b59a32082f409
SAO edge filter uses pre-SAO pixel data on the left and top of the ctb, so
this data must be kept available. This was done previously by having 2
copies of the frame, one before and one after SAO.
This commit reduces the storage to just that, instead of the previous whole
frame.
Commit message taken from patch by Christophe Gisquet <christophe.gisquet@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is currently always true, the assert protects against
future changes to the code breaking this assumtation
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9b8c8a9395c849639aea0f6b5300e991e93c3a73':
svq1dec: Validate the stages value strictly
Not merged, this is wrong, the condition is not possible
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3d5d46233cd81f78138a6d7418d480af04d3f6c8':
opus: Factor out imdct15 into a standalone component
Conflicts:
configure
libavcodec/opus_celt.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '28df0151b6618226b05ee52e031af0b11ca531b0':
configure: Add a dependency on vc1_decoder from vc1_parser
See: 6ac3c8c6a0
Merged-by: Michael Niedermayer <michaelni@gmx.at>
libopenjpegenc crashes with "pointer being freed was not allocated" when threading
is enabled with:
ffmpeg -i tests/vsynth1/01.pgm -vcodec libopenjpeg file.j2k
this appears to be a bug in libopenjpeg
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes builds with vc1_parser enabled without vc1_decoder. All
the vc1_decoder object files were included in the vc1_parser line
in libavcodec/Makefile before, but architecture specific object files
for vc1_decoder were not.
Signed-off-by: Martin Storsjö <martin@martin.st>
Prevents an 'Invalid packet' message. Currently mid-stream setup packets
are ignored. Theoretically, they could, based on the specification, be used to
reinitialize the stream if parameters change, but I don't expect that to be
common (and no one seems to have asked for it).
Signed-off-by: Ben Boeckel <mathstuf@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
For band filter, source and destination are aligned (except for 16x16 ctbs),
and otherwise, they are most often aligned. Overall, the total width is also
too small for amortizing memcpy.
Timings (using an intrinsic version of edge filters):
B/32 B/64 E/32 E/64
Before: 32045 93952 38925 126896
After: 26772 83803 33942 117182
This is probably unneeded and normal int would be fine, but its
safer to use LL and this isnt speed relevant
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Pass instead the two variables from the struct needed in the function.
This simplifies writing asm optimized versions of the function
Signed-off-by: James Almer <jamrial@gmail.com>
Since the decoder has been fixed to output something similar to
other implementations, the encoder weight table needed this fix.
Reference PSNR values on a progressive sequence (from tiny_psnr)
from a chained encoding and decoding:
Full progressive: stddev: 0.74 PSNR: 50.69 MAXDIFF: 19
Before: stddev: 1.43 PSNR: 44.97 MAXDIFF: 17
This patch: stddev: 0.76 PSNR: 50.44 MAXDIFF: 14
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* cehoyos/master:
lavc/arm: Use the neon vertical chroma loop filter also for H.264 4:2:2.
lavc/aarch64: Do not use the neon horizontal chroma loop filter for H.264 4:2:2.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '1a07df31128da3a0020b66502399989b91770d44':
DNxHD: Add support for id 1258 (DNx100 960x720@8)
Conflicts:
Changelog
libavcodec/dnxhddata.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '6996fd204a7f28b46a8c3c97bcf223998218c743':
libopenh264: Log debug messages to a non-null context
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '61928b68dc28e080b8c8191afe5541123c682bbd':
h264: Do not share rbsp_buffer across threads
Conflicts:
libavcodec/h264.c
See: ecbf838c7d
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This avoids a potential conflict with the equally named function for closing files
It also could reduce confusion in debugger backtraces
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Quite a few programs missed that detail of the spec
(including old versions of FFmpeg I believe) and when
we would otherwise fail anyway it seems worth a try
to use a simple byte-aligned stride instead.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
* commit 'a536a4e4bc52d05f59869761337452fb1f1977f6':
lavc: support extracting audio service type from side data
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '728685f37ab333ca35980bd01766c78d197f784a':
Add a side data type for audio service type.
Conflicts:
doc/APIchanges
libavcodec/avcodec.h
libavcodec/version.h
libavutil/frame.h
libavutil/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f771b3ab5d3c0b763ee356152be550f4121babd0':
avidec: do not export stream_codec_tag
Conflicts:
libavformat/avidec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '167e004e1aca7765686ed95d7cd8ea5064d4f6f6':
h264: drop any pretense of support for data partitioning
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ecab21ac47d0d4ca604bebf494017ae5090853a8':
h264: do not reset the ref lists in flush_change()
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9404a47a2d1df418946a338938eb6cdb3afed474':
h264: move parser-only variables to their own context
Conflicts:
libavcodec/h264_parser.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'cf1e0786ed64e69614760bfb4ecd7adbde8e6094':
error_resilience: move the MECmpContext initialization into ER code
Conflicts:
libavcodec/error_resilience.c
libavcodec/h264.c
libavcodec/h264.h
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '443b71928b2f36362e805c037751e6c3c79ea4e8':
hevc: unref the current frame if frame_start() fails
Conflicts:
libavcodec/hevc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
It does not work correctly and apparently never did. There is no
indication that this (mis)feature is ever used in the wild or even that
any software other than the reference supports it.
Since the code that attempts to support it adds some nontrivial
complexity and has resulted in several bugs in the past, it is better to
just drop it.
Currently, it needs to be initialized by the ER caller (which is
currently either a mpegvideo decoder or h264dec). However, since none of
those decoders use MECmpContext for anything except ER, it makes more
sense to handle it purely inside ER.
This should behave similar to x264 and other encoders, as it handles a
gop_size of 0 as Intra-Only, while it's still possible to control how
many B-Frames it inserts.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Before
2843 decicycles in ff_sbr_autocorrelate_sse3, 262086 runs, 58 skips
After
2693 decicycles in ff_sbr_autocorrelate_sse3, 262117 runs, 27 skips
Signed-off-by: James Almer <jamrial@gmail.com>
if the openjpeg parameter tcp_rates is not 0 ( using the ffmpeg compression_level option )
every 2nd image per thread is badly encoded. By moving the opj_setup_encoder function from
libopenjpeg_encode_init to libopenjpeg_encode_frame this can be prevented.
This fixes ticket #3754.
Signed-off-by: Jean First <jeanfirst@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This improves motion estimation and avoids using uninitialized data
for resolutions that aren't a multiple of 16.
Prior to d2a25c40, the edges used to be initialized so that encoding
was deterministic, but after that commit it started using uninitialized
data (for non multiple of 16 resolutions).
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
This like the previous attempt does not fully correctly decode this
type of non standard H.264, but it now works fully automatic
requiring no manual filters or flags to be used
See Ticket2254
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The vec_ste calls were mistakenly changed to vec_vsx_st in c5ca76a, which
caused stack smashing.
Changing them back fixes crashes on ppc64el, when configured with
--toolchain=hardened.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '440119b18836887d98c9e337c5911563bb43588c':
libopenh264enc: Move a declaration of a variable into an ifdef
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'bba02479260d0e7dec8c530a7e75a1c7aa53c06e':
libopenh264enc: Remove a workaround for silencing warnings about unused variables in the OpenH264 header
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The 1.3 release branch of OpenH264 (as well as the master branch)
have been updated so that GCC no longer warns about this variable
as being unused.
Signed-off-by: Martin Storsjö <martin@martin.st>
This leaked a frame on each avcodec_flush_buffers() call, if frame
threading was enabled. It caused severe memory usage in player if you
were seeking a lot.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes out of array reads and/or infinite loops.
30 is the maximum number of bits that can be read into
coeff_abs below.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Martin Storsjö <martin@martin.st>
Move the lavc/imgconvert functions and rename them as follows:
avpicture_get_size -> av_image_get_buffer_size()
avpicture_fill -> av_image_fill_arrays()
avpicture_layout -> av_image_copy_to_buffer()
The new functions have an align parameter, which allows to define the
linesize alignment assumed in the buffer (which is set or read).
The names of the functions are consistent with the lavu/samples API
(av_samples_get_buffer_size(), av_samples_fill_arrays()).
A redundant check has been dropped from av_image_fill_arrays().
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
If refdata was NULL, the memcpy() ended up copying the same memory
block onto itself, which is not only pointless, but also undefined
behavior.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Anshul Maheshwari <anshul.ffmpeg@gmail.com>
To test Closed caption use following command
ffmpeg -f lavfi -i "movie=input.ts[out0+subcc]" -map s output.srt
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This and the next commit improve error concealment for
green-block-artifacts-from-canon-100-hs.MOV
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Default libvpx msvc buils used module definition to export symbols.
These symbols are exported as pointers to data which dont link when
referenced directly.
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
With a certain fuzzed file, the parser will always return 0 consumed
bytes, which makes calling code call the parser infinitely. Return the
full packet size on error instead. (Here it would be nice if parsers
could return errors at all.)
Additionally, _if_ there's some data left, return that too, which might
help with somewhat broken but still somehow playable files.
Fixes ticket #4242.
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The parser must always set the out_size and out_data pointers. The API
seems to require it, and the common code in parser.c also relies on it.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
dvdsub_decode() can call append_to_cached_buf() 2 times, the second time
with ctx->buf as argument. If the second append_to_cached_buf() reallocs
ctx->buf, the argument will be a pointer to the previous, freed block.
This can cause invalid reads at least with some fuzzed files - and
possibly with valid files.
Since packets can apparently not be larger than 64K (even if packets are
combined), just use a fixed size buffer. It will be allocated as part of
the DVDSubContext, and although some memory is "wasted", it's relatively
minimal by modern standards and should be acceptable.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '2dbd35b00c6433e587d5f44d5dbc8972ebbaa88e':
libfdk-aacdec: Make sure decoding doesn't add any extra delay in the latest version of fdk-aac
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The latest version added support for a new option for enabling
a signal level limiter, which adds some extra delay. In fdk-aac, this
is enabled by default, but disable it by default here since we'd rather
have zero-delay decoding.
Signed-off-by: Martin Storsjö <martin@martin.st>
These have a DXSA tag and contain alpha in addition to
color values for palette.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* commit 'ed97963bdbf3bb17fca4f9ea0aa1a97722dec907':
ulti: invert the order of parameters of ulti_decode_frame()
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '2cef68da69a17ed09c313ba3c3850ec1cc0a80e0':
vda: error out if decoded CVPixelBuffer is empty
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ca09effb01e126b0ac74ff3de70a475423ddee82':
ffv1: Drop unnecessary casts and const qualifiers to match function signatures
Conflicts:
libavcodec/ffv1dec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Compared to existing, common opensource H264 encoders, this can be
useful since it has got a different license (BSD instead of GPL).
Performance- and qualitywise it is comparable to x264 in ultrafast
mode.
Hooking it up as an encoder in libavcodec also simplifies comparing
it against other common encoders.
This requires OpenH264 1.3 or newer. Since the OpenH264 API and ABI
changes frequently, only releases are supported.
To take advantage of the OpenH264 patent offer, the OpenH264 library
must not be redistributed, but downloaded at runtime at the end-user's
system.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is the order that the caller uses in the rest of the file.
Variables are modified to reflect the order above too and their
initialization is merged with their declarationt. No behavioral
change.
Bug-Id: CID 732286
x86inc can translate r*m into a register or stack on its own
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>
On some video samples, VDA silently fails to decode frames and returns
kVDADecoderNoErr. Error out in these cases to avoid producing AVFrames with
empty planes.
Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
The code blindly trusted buffer offsets read from the file in the RLE
decoder. Explicitly check the offset. Also error out on other RLE
decoding errors.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* rbultje/vp9-32bit-lpf:
vp9/x86: add myself to copyright holders for loopfilter assembly.
vp9/x86: make filter_16_h work on 32-bit.
vp9/x86: make filter_48/84/88_h work on 32-bit.
vp9/x86: make filter_44_h work on 32-bit.
vp9/x86: make filter_16_v work on 32-bit.
vp9/x86: make filter_48/84_v work on 32-bit.
vp9/x86: make filter_88_v work on 32-bit.
vp9/x86: make filter_44_v work on 32-bit.
vp8/x86: save one register in SIGN_ADD/SUB.
vp9/x86: store unpacked intermediates for filter6/14 on stack.
vp8/x86: move variable assigned inside macro branch.
vp9/x86: simplify ABSSUM_CMP by inverting the comparison meaning.
vp8/x86: remove unused register from ABSSUB_CMP macro.
vp9/x86: slightly simplify 44/48/84/88 h stores.
vp9/x86: make cglobal statement more conservative in register allocation.
vp9/x86: save one register in loopfilter surface coverage.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The r10k and avrp decoders would previously store 12 bit precision
for the blue channel, which is inconsistent and probably not a
desirable behaviour.
Now the 2 unused extra bits are set to 0.
This is possibly not ideal either as RGBA1010102 format has the same
layout but stores alpha in these bits, thus explicitly setting them
to 1 might be preferable.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
* commit '737d35e33408263c04d7730f5487eed0d04938ba':
vdpau: add support for the H.264 High 4:4:4 Predictive profile
Conflicts:
libavcodec/vdpau_internal.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ebd5320afd42d4315851f3e0ca7f5d4a6300eb68':
vdpau: add support for 4:2:2 and 4:4:4 chroma sampling
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'c220a60f92dde9c7c118fc4deddff5c1f617cda9':
vdpau: add helper for surface chroma type and size
Conflicts:
libavcodec/vdpau.c
libavcodec/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
