Fixes: out of array access
Fixes: ffmpeg_bof_1.avi
Found-by: Thuan Pham, Marcel Böhme, Andrew Santosa and Alexandru Razvan Caciulescu with AFLSmart
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit ed22dc2221)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is identical to what the VP9 parser does
Fixes: 9215/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LIBVPX_VP8_fuzzer-5768227253649408
Fixes: out of memory access
This may also fix oss fuzz issue 9212
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 284dde24da)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: integer overflow and out of array access
Fixes: asfo-crash-46080c4341572a7137a162331af77f6ded45cbd7
Found-by: Paul Ch <paulcher@icloud.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 2b46ebdbff)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: ffmpeg_crash_8.avi
Found-by: Thuan Pham, Marcel Böhme, Andrew Santosa and Alexandru Razvan Caciulescu with AFLSmart
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 95556e27e2)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: 8521/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DIRAC_fuzzer-5639024952737792
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit aa41d322be)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Regression since: af1761f7
Fixes: Division by 0
Fixes: ffmpeg_crash_1
Found-by: Thuan Pham, Marcel Böhme, Andrew Santosa and Alexandru Razvan Caciulescu with AFLSmart
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 16d8b13b3b)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: OOM
Fixes: 8195/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SHORTEN_fuzzer-5179785826271232
The reference software appears to use longs for 32bits and it uses int for nmeans
hinting that the intended maximum size was not 32bit.
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d91a0b503d)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Without this some operations might overflow (undefined behavior)
even though the index adding loop would never execute
No testcase known
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 56e76bd057)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes truncation
Fixes Assertion n <= 31 && value < (1U << n) failed at libavcodec/put_bits.h:169
Fixes: ffmpeg_crash_2.avi
Found-by: Thuan Pham <thuanpv@comp.nus.edu.sg>, Marcel Böhme, Andrew Santosa and Alexandru RazvanCaciulescu with AFLSmart
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit e1182fac1a)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This avoids inconsistent value combinations.
Alternatively it would be possible to add more checks and careful use of
temporary variables, but my try of this quickly seemed to become
a rather large change.
The disadvantage of this, is that the struct is copied back and forth.
Fixes: index 6 out of bounds for type 'const uint16_t [5][16]'
Fixes: 6557/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_INDEO4_fuzzer-4787296550256640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 10c8521265)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
also fixes: runtime error: index 1456 out of bounds for type 'int16_t [16]'
Found-by: durandal_1707
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d06b01fc2d)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The crc flag is only stored since version 3 thus before this crcs do not
work. We increase the version as needed same as we do with pix_fmts
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d9706f79c1)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Branch to global symbol results in reference to PLT, and when compiling
for THUMB-2 - in a R_ARM_THM_JUMP19 relocation. Some linkers don't
support this relocation (ld.gold), while others can end up truncating
the relocation to fit (ld.bfd).
Convert this branch through PLT into a direct branch that the assembler
can resolve locally.
See https://github.com/android-ndk/ndk/issues/337 for background.
The current workaround is to disable neon during gstreamer build,
which is not optimal and can be reverted after this patch:
41556c4157
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit b22db4f465)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: 18133149658382192 - -9223090561878065151 cannot be represented in type 'long long'
Fixes: crbug 831552
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 37d46dc21d)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 2147483646 - -2816 cannot be represented in type 'int'
Fixes: crbug 823145
Reported-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 8c02cd8ca0)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If there is a decoder initialization failure detected in avcodec_open2
after .init is called, allow graceful decoder .close to prevent leaking
libopus decoder allocations.
BUG=828526
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit e43e97f0e0)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes visual corruption on seeking
Fixes: downloadTest_clip_24M.rmvb
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 6cd81d68c5)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Removed +len1 in call to s->mix_2_1_f() as I found no logical explanation for it. After removal, problem was gone.
Signed-off-by: Hendrik Schreiber <hs@tagtraum.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 647fd4b829)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
example:
AVPixelFormat pixFmts[] = { AV_PIX_FMT_RGB24, AV_PIX_FMT_RGBA };
int loss = 0;
AVPixelFormat best = avcodec_find_best_pix_fmt_of_list(pixFmts, AV_PIX_FMT_BGRA, 1, &loss);
best is AV_PIX_FMT_RGB24. But AV_PIX_FMT_RGBA is better.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 354b26a394)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This avoids mixing 8bit variants with pro and 10bit with non pro mode.
Fixes: out of array read
Fixes: poc_03_30.avi
Found-by: GwanYeong Kim <gy741.kim@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 47b7c68ae5)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: -9166684017437101870 + -2495066639299164439 cannot be represented in type
Fixes: Chromium bug 791349
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 2f37082827)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 3775922176 * 4278190080 cannot be represented in type 'long'
Fixes: Chromium bug 791237
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 06e092e781)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Chromium bug 795653
Fixes: signed integer overflow: 9223372036854775807 + 1 cannot be represented in type 'long'
Reported-by: Matt Wolenetz <wolenetz@google.com>
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 02ecda4aba)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: 7738135736989908991 - -7898362169240453118 cannot be represented in type 'long'
Fixes: Chromium bug 796778
Reported-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 1b1362e408)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: 5 * -2147483647 cannot be represented in type 'int'
Fixes: Chromium bug 817338
Reviewed-by: Matt Wolenetz <wolenetz@google.com>
Reported-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 367929bed9)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: integer overflows
Reported-by: "Xiaohan Wang (王消寒)" <xhwang@chromium.org>
Based on limits in "8.5 Transform coefficient decoding process and picture
construction process prior to deblocking filter process"
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit f26a63c4ee)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When ff_h264_decode_mb_cavlc() failed due to wrong sl->qscale values,
e.g. dquant out of range, set the qscale to be a valid value before
returning -1 and exiting the function. The qscale value can be used
later e.g. in loop filter.
BUG=806122
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 71f39de2a5)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes part of ticket #7146, dealing with leaks of packet data since
commit 87c8812270.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit b8629654c6)
Nothing currently guarantees that the packet passed to the bsf will
be writable.
Based on commit 4f2ff3a53e
Signed-off-by: James Almer <jamrial@gmail.com>
Prefer direct in/out channel count values over channel layout, when
available. Fixes a pan filter bug (ticket #6790).
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
(cherry picked from commit 6325bd3717)
Defined in a recent revision of https://www.webmproject.org/docs/container/
This prevents storing the contents of CodecPrivate into extradata for
a codec that doesn't need nor expect any. It will among other things
prevent matroska specific binary data from being dumped onto other
formats during remuxing.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit acdea9e7c5)
For B field pictures, the spec says,
> The prediction shall be made from the field of the same parity as the field being predicted.
I did it.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 8b154cb3e9)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I suspect that this can be limited tighter, but i failed to find anything
in the spec that would confirm that.
Fixes: 4833/clusterfuzz-testcase-minimized-5302840101699584
Fixes: runtime error: left shift of 134217730 by 4 places cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit a026a3efae)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
use ffmpeg -h filter=deinterlace_vaapi can't get full help information,
the root cause is not setting the flags fileld in options.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 383804edd8)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Use perdefined micro __FUNCTION__ rather than hard coding function name
to fix wrong function name in error message.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 4280948702)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently the resource is only ever unregistered when the
registered_frames array is fully in use and an unmapped entry is re-used
and cleaned up.
I'm pretty sure the frame will have been cleaned up before that happens,
so I'm kinda surprised this never blew up.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
If some logic like vsync in ffmpeg.c duplicates frames, it might pass
the same frame twice, which will result in a crash due it being
effectively mapped and unmapped twice.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This prevents a possible crash in CreateDeviceEx when using faulty
response from GetAdapterDisplayModeEx and allows ffmpeg to fallback to
classic d3d9.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
(cherry picked from commit 59b126f922)
This partially reverts a change in behavior introduced in 2a111c99a6.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 7e60c74329)
x264 now supports multibitdepth builds, with a slightly changed API to
request bitdepth during initialization.
Reviewed-by: Ricardo Constantino <wiiaboo@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 2a111c99a6)
The x264_bit_depth constant has been removed in newer x264 builds.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 89f704caba)
In commit 061a0c14bb ("decode: restructure the core decoding code"), the
deprecated avcodec_decode_* APIs were reworked so that they called into the
new avcodec_send_packet / avcodec_receive_frame API. This had the side effect
of prohibiting sending new packets containing data after a drain
packet, but in previous versions of FFmpeg this "worked" and some
applications relied on it.
To restore some compatibility, reset the codec if we receive a new non-drain
packet using the old API after draining has completed. While this does
not give the same behaviour as the old API did, in the majority of cases
it works and it does not require changes to any other part of the decoding
code.
Fixes ticket #6775
Signed-off-by: James Cowgill <jcowgill@debian.org>
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit 02ba4b91b5)
2LL << (wrap_bits=64 - 1) does not fit in int64_t; change the
code to use a uint64_t (2ULL) and add an av_assert2() to
ensure wrap_bits <= 64.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 03fbc0daa7)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
An invalid file may cause huge alloc. Delay expansion of ctts entries
until the number of samples is known in mov_build_index.
Fixes: 23
Found-by: zhao dongzhuo, AD-lab of Venustech
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 2d015d3bf9)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The outputted bits should match what is used in the lossless check
Fixes: runtime error: signed integer overflow: -538697856 * 256 cannot be represented in type 'int'
Fixes: 4326/clusterfuzz-testcase-minimized-5689449645080576
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 97c00edaa0)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
decode_user_data() attempts to create an integer |build|
value with 8 bits of spacing for 3 components. However
each component is an int32_t, so shifting each component
is undefined for values outside of the 8 bit range.
This patch simply clamps input to 8-bits per component
and prints out a warning that the values were clamped.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 7010dd98b5)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These tables are static so they should only be initialized once
instead of on every call to ff_mpadsp_init().
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 5eaaffaf64)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Use of uninitialized memory
Fixes: assertion failure
Reviewed-by: <atomnuker>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 6d00905f81)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Avoid a use after free in avformat_find_stream_info.
(cherry picked from commit 9e4a5eb51b)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When a channel formula ends with a subtraction, the next formula will
otherwise have its first coefficient negated.
(cherry picked from commit 4f4e19914d)
It allows us to specify what kind of audio parameter changes are allowed.
Should fix ticket #6721.
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit d68a557df4)
Typically only a small subset of the SDL texture formats are supported directly
by the SDL renderer drivers, the rest is software emulated. It's better if
libswscale does the format conversion to a hardware-accelerated texture format
instead of SDL.
This should fix video render slowdowns with some texture formats after
3bd2228d05.
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit 415038f2bd)
Otherwise the frame size of the codec is not set in the buffersink.
Fixes ticket #6603 and the following simpler case:
ffmpeg -c aac -filter_complex "sine=d=0.1,asetnsamples=1025" out.aac
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit f4090940bd)
Since non-Haar wavelets need to look into pixels outside the frame, we
need to pad the buffer. The old factor of two seemed to be a workaround
that fact and only padded to the left and bottom. This correctly pads
by the slice size and as such reduces memory usage and potential
exploits.
Reported by Liu Bingchang.
Ideally, there should be no temporary buffer but the encoder is designed
to deinterleave the coefficients into the classical wavelet structure
with the lower frequency values in the top left corner.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
(cherry picked from commit 3228ac730c)
This was missed in e754c8e8 / e2710e790c since those functions
weren't exercised by checkasm.
Fixes ticket #6766.
(cherry picked from commit f1fd12ef85)
In the past XvMC forced simple_idct since
it was using FF_IDCT_PERM_NONE.
However now we have SIMD variants of simple_idct that
are using FF_IDCT_PERM_TRANSPOSE and if they are selected
XvMC would get coefficients in the wrong order.
The patch creates new FF_IDCT_NONE that
is used only for this kind of hardware decoding
and that fallbacks to the old C only simple idct.
Signed-off-by: Ivan Kalvachev <ikalvachev@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 9054439bad)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Should prevent some options from being added to cflags when they
don't exist and the compiler only warns about it.
Reviewd-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit ad56e8057d)
The public functions av_alloc_vdpaucontext() and
av_vdpau_alloc_context() are allocating AVVDPAUContext
structure that is supposed to be placed in avctx->hwaccel_context.
However the rest of libavcodec/vdpau.c uses avctx->hwaccel_context
as struct VDPAUHWContext, that is bigger and does contain
AVVDPAUContext as first member.
The usage includes write to the new variables in the bigger stuct,
without checking for block size.
Fix by always allocating the bigger structure.
Signed-off-by: Ivan Kalvachev <ikalvachev@gmail.com>
(cherry picked from commit 3a6ded7cfc)
We are not using dynamic loading for libndi.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit 58143b15ad)
Load the specific destination bytes instead of MSA load and pack.
Pack the data to half word before clipping.
Use immediate unsigned saturation for clip to max saving one vector register.
Signed-off-by: Kaustubh Raste <kaustubh.raste@imgtec.com>
Reviewed-by: Manojkumar Bhosale <Manojkumar.Bhosale@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes out of array read
Should fix: 3516/clusterfuzz-testcase-minimized-4608518562775040 (not reprodoceable)
Found-by: Insu Yun, Georgia Tech.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: signed integer overflow: -104713 * 65536 cannot be represented in type 'int'
Fixes: 3453/clusterfuzz-testcase-minimized-5555554657239040
Fixes: 3528/clusterfuzz-testcase-minimized-6283628420005888
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Can be tested via the following command:
./ffmpeg -i foo.ts -f decklink -vcodec v210 'DeckLink Duo (1)'
Note that the 8-bit support works as it did before, and setting
the pix_fmt isn't required for 10-bit mode. The code defaults to
operating in 8-bit mode when no vcodec is specified, for backward
compatibility.
Updated to reflect feedback from Marton Balint <cus@passwd.hu>
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Add support for enumerating the sources/sinks via the ffmpeg
command line options, as opposed to having to create a real pipeline
and use the "-list_devices" option which does exit() after dumping
out the options.
Note that this patch preserves the existing "-list_devices" option,
but now shares common code for the actual enumeration.
Updated to reflect feedback from Marton Balint <cus@passwd.hu>.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Remove the SDL_main define from the global cflags but not from the
ffplay cflags, and the -mwindows linker option from extralibs instead
of overriding it with the addition of -mconsole.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
When profile mismatch is allowed, use the highest supported profile for
VAAPI decoding.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
This reverts commit c2d155e11e.
GCC 6 incorrectly passes the configure test and then logs many warnings
of the form:
src/libavformat/dump.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-bool-operation’
The initialisation should be common. For libmfx, it was previously
happening in the derivation function and this moves it out. For VAAPI,
it fixes some failures when deriving from a DRM device because this
initialisation did not run.
This is an ABI change in libva2: previously the Intel driver had this
behaviour and it was implemented as a driver quirk, but now it is part
of the specification so all drivers must do it.
This has been deprecated in libva2 because hardware does not and will not
support it. Therefore never consider it for decode, and for encode assume
the user meant constrained baseline profile instead.
Since af1761f7b5 ffmpeg waits for a frame in each
stream before writing the output header. If we are using threaded decoding for
attached pictures, we have to read till EOF to be able to finally flush the
decoder and output the decoded frame. This essentially makes ffmpeg buffer all
non-attached picture packets, which will cause a "Too many packets buffered for
output stream" eventually.
By forcing single threaded decoding, we get a frame from a single packet as
well and we can avoid the error.
Fixes part of ticket #6375:
ffmpeg -i 46564100.mp3 -acodec libmp3lame -ab 128k -ac 2 out.mp3
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Allows to specify the action to be performed when reading the last frame
from the internal FIFO buffer. By default the last frame is written to
filter output depending on the timestamp rounding method. When using
"pass" action the last frame is passed through if input duration
has not been reached yet.
Examples using an input file with 25Hz, 1.4sec duration:
- "fps=fps=1:round=near" generates an output file of 1sec
- "fps=fps=1:round=near:eof_action=pass" generates an output file of
2sec
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Make easier to handle the polling function before we implement
full threading support.
(cherry picked from libav commit ca960161f0)
Signed-off-by: James Almer <jamrial@gmail.com>
These changes store id3 chapter data in ID3v2ExtraMeta and introduce
ff_id3v2_parse_chapters to parse them into the format context if needed.
Encoders using ff_id3v2_read, which previously parsed chapters into the
format context automatically, were adjusted to call
ff_id3v2_parse_chapters.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Split it off from install-data.
Among other things, this prevents spamming triplicate log lines during install.
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: James Almer <jamrial@gmail.com>
Add missing AV_OPT_FLAG_FILTERING_PARAM flag to "start_time" option.
Fix indent of "round" named constants and clear unused field values.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Align order of "start_time" option within fps filter documentation to actual
implementation. Also fix some documentation cosmetics.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Fixes out of array access
Fixes: crash-huf.avi
Regression since: 6b41b44149
This could also be fixed by adding checks in the C code that calls the dsp
Found-by: Zhibin Hu and 连一汉 <lianyihan@360.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some V4L2 drivers fail to allocate buffers when sizeimage is not set
to a max value. This is indeed the case for s5p-mfc [1]
Most drivers should be able to calculate this value from the frame
dimensions and format - or at least have their own default.
However since this work around should not impact those drivers doing
the "right thing" this commit just provides such a default.
The calculations were extracted from the v4l2 driver used to develop
the ffmpeg v4l2_m2m support [2]. See venc.c and vdec.c
[1] linux.git/drivers/media/platform/s5p-mfc
[2] linux.git/drivers/media/platform/qcom/venus/
The string is allocated with CFStringGetCString but was being
deallocated with free(), which would intermittently result in
a segmentation fault. Use the correct function for freeing the
allocated CFString.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
This FFmpeg-specific "fuzzer fix" was never perfect, but now it
stopped encoding of actual content with a big enough DTS shift.
This returns the function to its original state of results
before negative CTS offsets were added.
I remember dealing with this function before, but somehow had
forgotten about it during VDD. The test cases not tripping this
over also didn't help.
* commit 'd7b2bb5391bf55e8f9421bff7feb4c1fddfac4bf':
h264_sei: Check actual presence of picture timing SEI message
This commit is a noop, see 6a37abc59a
Merged-by: James Almer <jamrial@gmail.com>
* commit '21cca00dfeaec08ca93cf94ed33f4311cf1d8c84':
build: Explicitly disable external libraries when not explicitly enabled
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'd8f36a6aa33e9f904fa47caa0329ddaac391cd7d':
nvenc: Fix the preset mapping list
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c483398bb7ef66f61ed2dcb09f3d6160683da0eb':
build: Drop DOC_ prefix from EXAMPLES-related variables
Merged-by: James Almer <jamrial@gmail.com>
* commit '4141a5a240fba44b4b4a1c488c279d7dd8a11ec7':
Use modern avconv syntax for codec selection in documentation and tests
Merged-by: James Almer <jamrial@gmail.com>
The number of bits from bit #m to #n is n - m plus 1.
Signed-off-by: Ingo Brückl <ib@wupperonline.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'da8093f712d625db7ce4a2526fb52994e01921ec':
fate: Use bitexact optimizations in the svq3-2 test
This commit is a noop, see b591329c3a
Merged-by: James Almer <jamrial@gmail.com>
* commit '4cc0227040adb9efc63be6a5765e3214f5c6f662':
apetag: account for header size if present when returning the start position
apetag: fix flag value to signal footer presence
This commit is a noop, see
e8d6fef31684d874a680
Merged-by: James Almer <jamrial@gmail.com>
The first frame changes depending on --enable-memory-poisoning being
used to configure ffmpeg or not, even if requesting bitexact decoding.
Disable the test until this is fixed.
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '8e4d4efc67e154fdffd65964a7cfeef740320827':
fate: Add another SVQ3 test to increase coverage
Also included a fix from da8093f712.
The demuxer option "-ignore_editlist 1 " is temporarily added to the
test as well, to workaround a regression in the edit list mov parsing
code.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'b8f66c0838b4c645227f23a35b4d54373da4c60a':
aarch64: vp9itxfm: Reorder iadst16 coeffs
arm: vp9itxfm: Reorder iadst16 coeffs
aarch64: vp9itxfm: Reorder the idct coefficients for better pairing
arm: vp9itxfm: Reorder the idct coefficients for better pairing
aarch64: vp9itxfm: Avoid reloading the idct32 coefficients
arm: vp9itxfm: Avoid reloading the idct32 coefficients
arm: vp9lpf: Implement the mix2_44 function with one single filter pass
aarch64: vp9lpf: Use dup+rev16+uzp1 instead of dup+lsr+dup+trn1
arm/aarch64: vp9lpf: Keep the comparison to E within 8 bit
This commit is a noop, see
3fbbad2984f32690a298a88db8b9a0600f4c9b032905657b904f693b56bdf952273019b2e20d898426ee83acc4
Merged-by: James Almer <jamrial@gmail.com>
* commit 'ed6a891c364f8b0850b557d9578b8920cc15a937':
Place attribute_deprecated in the right position for struct declarations
This commit is a noop, see
99530387286ff3da4f6a
Merged-by: James Almer <jamrial@gmail.com>
* commit '04d2afa93b6c6f320ac45dd99ce1226f3c3d5ac8':
mkv: Update the seek test to match 5d3953a5dc
fate: Update fate-lavf-mkv after commit 5d3953a5dc
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
It leaks memory and destroys the dst packet in case of failure, and it
ultimately duplicates functionality already existing in the saner
av_packet_copy_props().
Reviewed-by: wm4
Signed-off-by: James Almer <jamrial@gmail.com>
* commit 'c95169f0ec68bdeeabc5fde8aa4076f406242524':
build: Move cli tool sources to a separate subdirectory
Merged-by: James Almer <jamrial@gmail.com>
Revert back to the test as done by commit af7a75cb51,
where it was changed to compile and not just preprocess to fix build failures on
FreeBSD with gcc 4.7
Signed-off-by: James Almer <jamrial@gmail.com>
Correctly set the interlaced_frame and top_field_first fields when pic_struct
indicates paired fields.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'ab566cc96bc0c31b34d944214bc06cec8ae8b640':
build: Separate logic for building examples from that for building avtools
Merged-by: James Almer <jamrial@gmail.com>
* commit 'acb0dea27efff4b35796015b96570b59fd517078':
build: Split logic for building examples off into a separate Makefile
We already have a Makefile in doc/examples, but it's separate from the build
system and meant to be installed as part of the documentation to help users
compile the installed .c example files.
Move it to Makefile.example to make place for the new build system Makefile.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'db4903eb4875bed6c5b8a4259cdd7bc1768dfdf6':
build: Avoid duplication in examples lists
See 1a88e84fd5
Merged-by: James Almer <jamrial@gmail.com>
Prevents int->float conversions on every loop.
Performance gain on synthetic benchmarks: 13%.
Suggested by kamedo2.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
* commit '7208e5b5d638d4b9c2784036b4fc5728f32233c7':
configure: Restructure the way check_pkg_config() operates
Merged-by: James Almer <jamrial@gmail.com>
In preparation to make VANC decode modular, to support multiple other VANC data.
Signed-off-by: Karthick J <kjeyapal@akamai.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
The decklink input pixel format can now be specified with the 'raw_format'
option. The -bm_v210 option is now deprecated.
Signed-off-by: Marton Balint <cus@passwd.hu>
* commit '54e39b102e29adcc2f59f1eca85be5f86c89454b':
configure: Explicitly spell out first require_pkg_config() parameter
Merged-by: James Almer <jamrial@gmail.com>
* commit '42cf7f91f1e9dabf494ff469d8f67ac8b33b0f63':
dv: Don't return EIO upon EOF
This commit is a noop, see 3eae98c1ac
Merged-by: James Almer <jamrial@gmail.com>
* commit '7cb9296db872c4221453e5411f242ebcfca62664':
webp: Fix alpha decoding
This commit is a noop.
[13:09:40] <jamrial> jkqxz: do we need 7cb9296db8 from libav?
[13:11:20] <+wm4> we had vaapi vp8 for a while in ffmpeg, so I guess not
[13:11:58] <@jkqxz> It's more fallout from the VP8 hwaccel which never got merged. Some people hated on that part of the patch and I wasn't really interested in pursuing it further.
[13:13:02] <jamrial> it wasn't merged?
[13:13:21] <@jkqxz> wm4: There is no VP8 decode hwaccel in ffmpeg (there is encode).
[13:13:25] <+wm4> ah
[13:14:00] <jamrial> what do i do then? and shouldn't that be merged at some point?
[13:14:37] <@jkqxz> It should.
[13:14:53] <@jkqxz> Skip the patch now, though.
[13:16:30] <jamrial> ok, thanks
Merged-by: James Almer <jamrial@gmail.com>
This reduces the need for an edit list; streams that start with
e.g. dts=-1, pts=0 can be encoded as dts=0, pts=0 (which is valid
in mov/mp4) by shifting the dts values of all packets forward.
This avoids the need for edit lists for such streams (while they
still are needed for audio streams with encoder delay).
This eases conformance with the DASH-IF interoperability guidelines.
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '2d518aec4c781316092be65893b47922c8f71b67':
vf_deinterlace_vaapi: Create filter buffer after context
vaapi_encode: Discard output buffer if picture submission fails
This commit is a noop, see
92bd089745359586f14f
Merged-by: James Almer <jamrial@gmail.com>
* commit '8f5de34c8fb18fa1416e77d2cb998773a49ddb3d':
vf_fade: Make sure to not miss the last lines of a frame
This commit is a noop.
[11:00:43] <jamrial> michaelni: what do you think of 8f5de34c8f? does it apply to us?
[11:01:50] <jamrial> our code started to deviate with your commit bca59d7745, followed by the merge commit aa40df483b
[11:33:51] <michaelni> jamrial, the fade commits are from 2013, but i think our fixes where complete and the problematic slice_h FFALIGN is also removed
Merged-by: James Almer <jamrial@gmail.com>
* commit '8847eeaa141898850381400000fb2b8a7adc7100':
aarch64: Add parentheses around the offset parameter in movrel
This commit is a noop, see dda45c087b
Merged-by: James Almer <jamrial@gmail.com>
* commit '82989bd98c7f4e87f59af2147b645b8fd8f31c53':
avconv: Move rescale to stream timebase before monotonisation
This commit is a noop, see 4ee5aed122
Merged-by: James Almer <jamrial@gmail.com>
* commit '030de53e9cc225dc767458aedcc87efd457b4f3b':
libopenh264dec: Let the framework use the h264_mp4toannexb bitstream filter
Merged-by: James Almer <jamrial@gmail.com>
* commit '0539d84d985e811e5989ef27c13f7e2dda0f9b89':
asfdec: Account for different Format Data sizes
See 76853a3e0c
Merged-by: James Almer <jamrial@gmail.com>
* commit '871b4f3654636ed64560e86b9faa33828d195ceb':
configure: Check for xcb as well as xcb-shape before enabling libxcb
This commit is a noop. We already check for libxcb_shape.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'b446f0e98f85e2e931b476e52b319f1c49244660':
mov: Do not try to parse multiple stsd for the same track
See 8b43ee4054
Merged-by: James Almer <jamrial@gmail.com>
* commit 'e791b915c774408fbc0ec9e7270b021899e08ccc':
hwcontext_vaapi: Try to support the VDPAU wrapper
This commit is a noop, see f2e4fb61af
Merged-by: James Almer <jamrial@gmail.com>
* commit '5dd9a4b88b287bf8c93520afda7becb1ad0d1894':
vaapi: Implement device-only setup
This commit is a noop, see 81b7deab82
Merged-by: James Almer <jamrial@gmail.com>
* commit '44f2eda39ff55c69d4d739fb12a42a10b7ce581c':
lavc: Add device context field to AVCodecContext
This commit is a noop, see c1a5fca06f
Merged-by: James Almer <jamrial@gmail.com>
* commit '07b5136c481d394992c7e951967df0cfbb346c0b':
aarch64: vp9lpf: Fix broken indentation/vertical alignment
aarch64: vp9lpf: Interleave the start of flat8in into the calculation above
arm: vp9lpf: Interleave the start of flat8in into the calculation above
This commit is a noop, see
83399cf5699f3a886364c8d6eec85d
Merged-by: James Almer <jamrial@gmail.com>
* commit 'ba30b74686f0cb6c9dd465ac4820059c48bf9d08':
aac: Validate the sbr sample rate before using the value
See cf5f4c5169
Merged-by: James Almer <jamrial@gmail.com>
* commit '0ee78020cd41d81eec651acd7fc65906207796f3':
configure: Move up the avbuild directory creation
This commit is a noop, see 19bf50406e
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c2f97f050870897575570708ac48c5c15e6a0dd8':
hwcontext_dxva2: support D3D9Ex
This commit is a noop, see 50708f4aa4
Merged-by: James Almer <jamrial@gmail.com>
* commit '04f3bd349651694f30feeb8c4ed9bc58106fca54':
AVFrame: add an opaque_ref field
This commit is a noop, see e3af49b14b
Merged-by: James Almer <jamrial@gmail.com>
* commit 'e6bff23f1e11aefb16a2b5d6ee72bf7469c5a66e':
cpu: add a function for querying maximum required data alignment
Adapted to work with the arbitrary runtime cpuflag changes av_force_cpu_flags()
can generate.
Merged-by: James Almer <jamrial@gmail.com>
* commit '5c8a5765dc5f4e29afb85b95be393c30f45412a8':
scale_npp: explicitly set the output frames context for passthrough mode
See 62b75537db
Merged-by: James Almer <jamrial@gmail.com>
* commit '6f554521afdf7ab4edbfaa9536660a1dca946b19':
Use the new AVIOContext destructor.
avio: add a destructor for AVIOContext
This commit is a noop, see
b12e4d3bb878a7af823b
Merged-by: James Almer <jamrial@gmail.com>
* commit '435cd7bc99671bf561193421a50ac6e9d63c4266':
arm: vp9lpf: Use orrs instead of orr+cmp
arm/aarch64: vp9lpf: Calculate !hev directly
aarch64: vp9itxfm: Optimize 16x16 and 32x32 idct dc by unrolling
arm: vp9itxfm: Optimize 16x16 and 32x32 idct dc by unrolling
aarch64: vp9mc: Calculate less unused data in the 4 pixel wide horizontal filter
arm: vp9mc: Calculate less unused data in the 4 pixel wide horizontal filter
aarch64: vp9mc: Simplify the extmla macro parameters
This commit is a noop, see
ac6cb8ae5bbff0771590045e33ae3f758302e4bc148cc0bb89f0ecbb13cf92ab8374b1
Merged-by: James Almer <jamrial@gmail.com>
* commit 'b6093e8c72a80710f086c678ab0730cf30953b5c':
hlsenc: Correctly write down all 16 bytes in hex
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'bc2589763042dc2384b724b203ec778f35bcebad':
utvideodec: Add a missing include
This commit is a noop, see 91ed4e7196
Merged-by: James Almer <jamrial@gmail.com>
* commit 'a52976c0feab6e86138983c248bd01fa45cdda69':
nvenc: make gpu indices independent of supported capabilities
This commit is a noop, see 5403d90f32
Merged-by: James Almer <jamrial@gmail.com>
* commit '77c23704c769168e4210956314775a1931f6aa0b':
avcodec: Mark some codecs with threadsafe init as such
This commit is a noop, see 91ed4e7196
Merged-by: James Almer <jamrial@gmail.com>
* commit '0c0b87f12d48d4e7f0d3d13f9345e828a3a5ea32':
aarch64: vp9itxfm: Fix incorrect vertical alignment
aarch64: vp9itxfm: Update a comment to refer to a register with a different name
aarch64: vp9itxfm: Use the right lane sizes in 8x8 for improved readability
aarch64: vp9itxfm: Use a single lane ld1 instead of ld1r where possible
aarch64: vp9itxfm: Share instructions for loading idct coeffs in the 8x8 function
arm: vp9itxfm: Share instructions for loading idct coeffs in the 8x8 function
aarch64: vp9itxfm: Do separate functions for half/quarter idct16 and idct32
arm: vp9itxfm: Do a simpler half/quarter idct16/idct32 when possible
aarch64: vp9itxfm: Move the load_add_store macro out from the itxfm16 pass2 function
arm: vp9itxfm: Move the load_add_store macro out from the itxfm16 pass2 function
aarch64: vp9itxfm: Make the larger core transforms standalone functions
arm: vp9itxfm: Make the larger core transforms standalone functions
This commit is a noop, see
f8fcee0dafdc47bf38723bd9b39108a681c793a3824589556c9532a7d4d01d8ab576a73006e5253a19a0f9529c6752318c73d0fbf7f34e16ef000799
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c546147db07d16a76c2fb698d2e8a3057f393475':
configure: Correctly recurse in do_check_deps()
See 7659f35638.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'dad7a9c7c0ae8ebc56f2e3a24e6fa4da5c2cd491':
configure: Rework dependency handling for conflicting components
Includes an important fix made by c546147db0
as well.
Merged-by: James Almer <jamrial@gmail.com>
This adds hardware decoding for H.264 / HEVC / VP8 / VP9 using the MPP
Rockchip API. It returns frames holding an AVDRMFrameDescriptor struct
in buf[0] that allows drm / dmabuf usage. Tested on RK3288 (TinkerBoard)
and RK3328.
Signed-off-by: Mark Thompson <sw@jkqxz.net>
* commit '9127ac5ebc941d5e54828a91e5072c876be8ec42':
configure: Add name parameter to require_pkg_config() helper function
Merged-by: James Almer <jamrial@gmail.com>
Support for this device has been removed in kernel since v2.6.37. dv1394 has been superseded by libiec61883 which is functionally equivalent.
Signed-off-by: Josh de Kock <josh@itanimul.li>
Signed-off-by: wm4 <nfxjfg@googlemail.com>
* commit '71a49fe25f2e4468fbbadbebef8d073b1b3cc1a5':
configure: Use cppflags check helper functions where appropriate
Merged-by: James Almer <jamrial@gmail.com>
Metadata filter output is passed through an Awk script comparing floats
against reference values with specified "fuzz" tolerance to account for
architectural differences (e.g. x86-32 vs. x86-64).
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
* commit '58d87e0f49bcbbc6f426328f53b657bae7430cd2':
aarch64: vp9itxfm: Restructure the idct32 store macros
arm: vp9itxfm: Avoid .irp when it doesn't save any lines
This commit is a noop, see
31e41350d252c7366c83
Merged-by: James Almer <jamrial@gmail.com>
This reverts commit 740e557d6e, reversing
changes made to 932e28b13e.
The commit apparently broke builds with shared libs, and "suggesting"
the use of external libraries that need to be explicitly enable has
dubious usefulness anyway.
* commit '740b0bf03b4bb8b0a0e964750817ac0363a33c55':
build: Ignore generated .version files
This commit is a noop, see fbc304239f
Merged-by: James Almer <jamrial@gmail.com>
* commit 'acfa7a2178f08fd81b66279959cd55ec3ae237e2':
configure: Drop weak dependencies on external libraries for webm muxer
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit '3ad825793a43253154bed05827f27425fc0757df':
hwcontext_cuda: implement frames_get_constraints
This commit is a noop, c16fe1432d
Merged-by: James Almer <jamrial@gmail.com>
* commit 'b420a27e74750b60d2e064236afb10be06a38ace':
avconv: allow -b to be used with streamcopy
This commit is a noop. We already have this functionality.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'ab2539bd374fe7ddbc6e2f058b62645cd5076192':
ffv1: Convert to the new bitstream reader
h261dec: Convert to the new bitstream reader
shorten: Convert to the new bitstream reader
ralf: Convert to the new bitstream reader
loco: Convert to the new bitstream reader
fic: Convert to the new bitstream reader
dirac: Convert to the new bitstream reader
cavs: Convert to the new bitstream reader
aic: Convert to the new bitstream reader
golomb: Convert to the new bitstream reader
This commit is a noop, see
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html
Merged-by: James Almer <jamrial@gmail.com>
* commit '612cc0712836af2f025b0c68b11da29b9f259d5a':
pgssubdec: reset rle_data_len/rle_remaining_len on allocation error
This commit is a noop, see 842e98b4d8
Merged-by: James Almer <jamrial@gmail.com>
* commit 'ca62236a89f47bd871eaf69d8d9e837c93c55a6c':
vaapi_encode: Add VP8 support
vaapi_encode: Pass framerate parameters to driver
vaapi_h264: Enable VBR mode
vaapi_encode: Support VBR mode
This commit is a noop, see
ceb28c3cc42201c02e6dbe6546a4ffd1acab8293
Merged-by: James Almer <jamrial@gmail.com>
* commit 'dce2929efa8e82b0832a828f7e8cb81ff8c20a4e':
dashenc: copy language and role metadata from streams assigned to sets
Merged-by: Rodger Combs <rodger.combs@gmail.com>
* commit 'efd2fc41b3f0749f9715d50b581f22bbaa8c5b99':
dashenc: allow assigning all streams of a media type to an AdaptationSet
Merged-by: Rodger Combs <rodger.combs@gmail.com>
* commit '3d23a5f96ad72961c14ba3a0c2add8f2ab374b61':
dashenc: add support for assigning streams to AdaptationSets
Merged-by: Rodger Combs <rodger.combs@gmail.com>
* commit '9df9309d233f59d9706444a1e24ac24139f2640d':
dashenc: calculate stream bitrate from first segment if not available
Merged-by: Rodger Combs <rodger.combs@gmail.com>
The GnuTLS version is checked through the macro GNUTLS_VERSION_NUMBER,
but this wasn't introduced before 2.7.2. Building with older versions
of GnuTLS (using icc) warns:
src/libavformat/tls_gnutls.c(38): warning #193: zero used for undefined preprocessing identifier "GNUTLS_VERSION_NUMBER"
#if HAVE_THREADS && GNUTLS_VERSION_NUMBER <= 0x020b00
This adds a fallback to the older, deprecated LIBGNUTLS_VERSION_NUMBER
macro.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Commit 598e416840 added use of
GNUTLS_E_PREMATURE_TERMINATION, which wasn't introduced to GnuTLS
before 2.99.x / 3.x. This fixes compilation with older versions.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Duration depends on the selected subsong and thus must be queried after
selecting the subsong. There is no compelling reason to query other
metadata earlier either.
Tested with libopenmpt version: 0.2.8760-beta27
Libopenmpt configure options: --without-ogg --without-vorbis
--without-vorbisfile --without-portaudio --without-portaudiocpp
--without-mpg123 --without-pulseaudio --without-sndfile --without-flac
Signed-off-by: Jörn Heusipp <osmanx@problemloesungsmaschine.de>
Signed-off-by: Josh de Kock <josh@itanimul.li>
Load the specific destination bytes instead of MSA load and pack.
Pack the data to half word before clipping.
Use immediate unsigned saturation for clip to max saving one vector register.
Signed-off-by: Kaustubh Raste <kaustubh.raste@imgtec.com>
Reviewed-by: Manojkumar Bhosale <Manojkumar.Bhosale@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In case we are short of queued buffers, at first v4l2_buffer was enqueued to kernel so it's not owned by
user-space anymore. After that it's timestamp field was read, but it might be overwritten by driver at
that moment. It resulted in invalid timestamp sometimes.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit implements a psychoacoustic system for the native Opus
encoder. Its unlike any other psychoacoustic system known since its
capable of using a lookahead to make better choices on how to treat the
current frame and how many bits to allocate for it (and future frames).
Also, whilst the main bulk of the analysis function has to run in a
single thread, the per-frame anaylsis functions does not modify the main
psychoacoustic context, so in the future it will be fairly trivial to
run those as slice threads.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This patchset enhances Alexis Ballier's original patch and validates
it using Qualcomm's Venus hardware (driver recently landed upstream
[1]).
This has been tested on Qualcomm's DragonBoard 410c and 820c
Configure/make scripts have been validated on Ubuntu 10.04 and
16.04.
Tested decoders:
- h264
- h263
- mpeg4
- vp8
- vp9
- hevc
Tested encoders:
- h264
- h263
- mpeg4
Tested transcoding (concurrent encoding/decoding)
Some of the changes introduced:
- v4l2: code cleanup and abstractions added
- v4l2: follow the new encode/decode api.
- v4l2: fix display size for NV12 output pool.
- v4l2: handle EOS (EPIPE and draining)
- v4l2: vp8 and mpeg4 decoding and encoding.
- v4l2: hevc and vp9 support.
- v4l2: generate EOF on dequeue errors.
- v4l2: h264_mp4toannexb filtering.
- v4l2: fixed make install and fate issues.
- v4l2: codecs enabled/disabled depending on pixfmt defined
- v4l2: pass timebase/framerate to the context
- v4l2: runtime decoder reconfiguration.
- v4l2: add more frame information
- v4l2: free hardware resources on last reference being released
- v4l2: encoding: disable b-frames for upstreaming (patch required)
[1] https://lwn.net/Articles/697956/
System Level view:
v42l_m2m_enc/dec --> v4l2_m2m --> v4l2_context --> v4l2_buffers
Reviewed-by: Jorge Ramirez <jorge.ramirez-ortiz@linaro.org>
Reviewed-by: Alexis Ballier <aballier@gentoo.org>
Tested-by: Jorge Ramirez <jorge.ramirez-ortiz@linaro.org>
Signed-off-by: wm4 <nfxjfg@googlemail.com>
change the hlsenc from hls encryption to hlsenc
Suggested-by: Aman Gupta <aman@tmm1.net>
Reviewed-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Steven Liu <lq@onvideo.cn>
GnuTLS is too strict on the SSL shutdown alert, and it's neither
mandatory in the spec or critical. As it's ignored in OpenSSL, we
should also suppress it in GnuTLS as well.
Ticket: #6667
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
All DRM formats are defined in terms of little-endian words, so RGB formats
like XRGB actually have the elements in the opposite order order in memory
to the order they are in the name.
This does not affect YUYV and similar YUV 4:2:2 formats, which are in the
expected order.
VP9SharedContext needs to be the first member so its properties can be
safely accessed from hardware accelerators, without the need to share
the full VP9Context.
Fixes ticket #6674.
This is the equivalent to what 7d317d4706
did for the codec-specific options.
av_opt_copy has specific handling so it's fine that we already copied
the whole context before.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The complex vertical low-pass filter slightly over-sharpens the picture. This becomes visible when several transcodings are cascaded and the error potentises, e.g. some generations of HD->SD SD->HD.
To prevent this behaviour the destination pixel must not exceed the source pixel when the average of the pixels above and below is less than the source pixel. And the other way around.
Tested and approved in a visual transcoding cascade test by video professionals.
SSIM/PSNR test with the first generation of an HD->SD file as a reference against the 6th generation(3 x SD->HD HD->SD):
Results without the patch:
SSIM Y:0.956508 (13.615881) U:0.991601 (20.757750) V:0.993004 (21.551382) All:0.974405 (15.918463)
PSNR y:31.838009 u:48.424280 v:48.962711 average:34.759466 min:31.699297 max:40.857847
Results with the patch:
SSIM Y:0.970051 (15.236232) U:0.991883 (20.905857) V:0.993174 (21.658049) All:0.981290 (17.279202)
PSNR y:34.412108 u:48.504454 v:48.969496 average:37.264644 min:34.310637 max:42.373392
Signed-off-by: Thomas Mundt <tmundt75@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
DRM_FORMAT_R8 was added in libdrm 2.4.68.
DRM_FORMAT_R16 was added in libdrm 2.4.82.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
Intended for use with hardware frames for which rawvideo is not
sufficient. Requires the trusted packet flag to be set - decoding
fails if not to avoid security issues (the wrapped AVFrame can
contain pointers to arbitrary data).
Should fix the following tsan warning:
WARNING: ThreadSanitizer: data race (pid=19806)
Read of size 4 at 0x7b84000012f0 by thread T9:
#0 worker src/libavcodec/frame_thread_encoder.c:66 (ffmpeg+0x0000007f349e)
[..]
Previous write of size 4 at 0x7b84000012f0 by main thread (mutexes: write M1395):
#0 ff_frame_thread_encoder_free src/libavcodec/frame_thread_encoder.c:239 (ffmpeg+0x0000007f379e)
[..]
Fixes: runtime error: left shift of 1073741838 by 1 places cannot be represented in type 'int32_t' (aka 'int')
Fixes: 3279/clusterfuzz-testcase-minimized-4564805744590848
Suggested-by: <atomnuker>
Reviewed-by: <atomnuker>
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ffmpeg need a dash demuxer for demux the dash formats base on
https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/000001_add_dash_demux.patch
TODO:
1. support multi bitrate dash.
v2 fixed:
1. from autodetect to disabled
2. from camelCase code style to ffmpeg code style
3. from RepType to AVMediaType
4. fix variable typo
5. change time value from uint32_t to uint64_t
6. removed be used once API
7. change 'time(NULL)`, except it is not 2038-safe.' to av_gettime and av_timegm
8. merge complex free operation to free_fragment
9. use API from snprintf to av_asprintf
v3 fixed:
1. fix typo from --enabled-xml2 to --enable-xml2
v4 fixed:
1. from --enable-xml2 to --enable-libxml2
2. move system includes to top
3. remove nouse includes
4. rename enum name
5. add a trailing comma for the last entry enum
6. fix comment typo
7. add const to DASHContext class front
8. check sscanf if return arguments and give warning message when error
9. check validity before free seg->url and seg
10. check if the val is null, before use atoll
v5 fixed:
1. fix typo from mainifest to manifest
v6 fixed:
1. from realloc to av_realloc
2. from free to av_free
v7 fixed:
1. remove the -lxml2 from configure when require_pkg_config
v8 fixed:
1. fix replace filename template by av_asprintf secure problem
v9 modified:
1. make manifest parser clearly
v10 fixed:
1. fix function API name code style
2. remove redundant strreplace call
3. remove redundant memory operation and check return value from get_content_url()
4. add space between ) and {
5. remove no need to log the value for print
v11 fixed:
1. from atoll to strtoll
Suggested-by: Michael Niedermayer <michael@niedermayer.cc>
v12 fixed:
1. remove strreplace and instead by av_strreplace
Suggested-by: Nicolas George <george@nsup.org>
v13 fixed:
1. fix bug: cannot play:
http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd
Reported-by: Andy Furniss <adf.lists@gmail.com>
v14 fixed:
1. fix bug: TLS connection was non-properly terminated
2. fix bug: No trailing CRLF found in HTTP header
Reported-by: Andy Furniss <adf.lists@gmail.com>
v15 fixed:
1. play youtube link: ffmpeg -i $(youtube-dl -J "https://www.youtube.com/watch?v=XmL19DOP_Ls" | jq -r ".requested_formats[0].manifest_url")
2. code refine for timeline living stream
Reported-by: Ricardo Constantino <wiiaboo@gmail.com>
v16 fixed:
1. remove the snprintf and instead by get_segment_filename make safety
2. remove unnecessary loops
3. updated xmlStrcmp and xmlFree to av_* functions
4. merge code repeat into one function
5. add memory alloc faild check
6. update update_init_section and open_url
7. output safety error message when filename template not safe
Suggested-by : wm4 <nfxjfg@googlemail.com>
v17 fixed:
1. add memory alloc faild check
2. fix resource space error at free_representation
v18 fixed:
1. add condition of template format
v19 fixed:
1. fix typo of the option describe
v20 fixed:
1. add the c->base_url alloc check
2. make the DASHTmplId same to dashenc
v21 fixed:
1. remove get_repl_pattern_and_format and get_segment_filename
2. process use dashcomm APIs
v22 fixed:
1. modify the include "dashcomm.h" to include "dash.h"
2. use internal API from dash_fill_tmpl_params to ff_dash_fill_tmpl_params
Signed-off-by: Steven Liu <lq@onvideo.cn>
Signed-off-by: samsamsam <samsamsam@o2.pl>
- there is no need for kCVImageBufferColorPrimaries_ITU_R_2020 checks,
it's done at runtime
- VideoToolbox presence is now checked with check_apple_framework()
- link to CoreServices is only done when videotoolbox is enabled
$headers is a variable set in the context of other functions (we don't
use the "local" keyword in our scripts, so those variables are global).
Currently, when checking for AVFoundation/AVFoundation.h, the actual
enabled header is math.h.
Similarly, when testing for QuartzCore/CoreImage.h, the actual enabled
header is CoreGraphics/CoreGraphics.h.
This is completely broken and may be the reason why these checks are
made in random places.
Refer to "checkasm: use perf API on Linux ARM*" commit for the
rationale.
The implementation is somehow duplicated with checkasm, but so is the
current usage of AV_READ_TIME(). Until these implementations and
heuristics are made consistent, I don't see a way of sharing that code.
Note: when using libavutil/timer.h, it is now important to include
before any other include due to the _GNU_SOURCE requirement.
On ARM platforms, accessing the PMU registers requires special user
access permissions. Since there is no other way to get accurate timers,
the current implementation of timers in FFmpeg rely on these registers.
Unfortunately, enabling user access to these registers on Linux is not
trivial, and generally involve compiling a random and unreliable github
kernel module, or patching somehow your kernel.
Such module is very unlikely to reach the upstream anytime soon. Quoting
Robin Murphin from ARM:
> Say you do give userspace direct access to the PMU; now run two or more
> programs at once that believe they can use the counters for their own
> "minimal-overhead" profiling. Have fun interpreting those results...
>
> And that's not even getting into the implications of scheduling across
> different CPUs, CPUidle, etc. where the PMU state is completely beyond
> userspace's control. In general, the plan to provide userspace with
> something which might happen to just about work in a few corner cases,
> but is meaningless, misleading or downright broken in all others, is to
> never do so.
As a result, the alternative is to use the Performance Monitoring Linux
API which makes use of these registers internally (assuming the PMU of
your ARM board is supported in the kernel, which is definitely not a
given...).
While the Linux API is obviously cross platform, it does have a
significant overhead which needs to be taken into account. As a result,
that mode is only weakly enabled on ARM platforms exclusively.
Note on the non flexibility of the implementation: the timers (native
FFmpeg vs Linux API) are selected at compilation time to prevent the
need of function calls, which would result in a negative impact on the
cycle counters.
When parsing a monochrome file, chroma_log2_weight_denom was used without
being initialized, which could lead to a bogus error message being printed, e.g.
[h264 @ 0x61a000026480] chroma_log2_weight_denom 24576 is out of range
It also could led to warnings using AddressSanitizer.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Use the earliest input with the same status.
If that fails, print a warning and use the earliest source.
With this change, simple filter forward correctly the timestamp
of EOF.
Filters that are supposed to change it should be updated to
actually forward it.
Adds another test for asetnsamples filter where padding of the last
frame is switched off. Renames the existing test to make the difference
obvious.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Fixes: Missing EOF check in loop
No testcase
Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Missing EOF check in loop
No testcase
Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Makes the handling of unspecified/unknown color_range values on stream
level consistent to the value used on frame level.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
merge from libav: 585dc1aece
If the metadata packet is corrupted, flv_read_metabody can accidentally
read past the start of the next packet. If the start of the next packet
had been flushed out of the IO buffer, we would be unable to seek to
the right position (on a nonseekable stream).
Prefer to clearly error out instead of silently trying to read from a
desynced stream which will only be interpreted as garbage.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Extradata may be allocated and the AudioConverterRef may be created during init(),
which in case of a failure would not be freed as close() isn't called afterwards.
Signed-off-by: James Almer <jamrial@gmail.com>
This flag replaces the deprecated, non-prefixed HWACCEL_CODEC_CAP_EXPERIMENTAL
one.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: runtime error: signed integer overflow: 1168175789 + 1168178473 cannot be represented in type 'int'
Fixes: 3081/clusterfuzz-testcase-minimized-4807564879462400
Fixes: 2844/clusterfuzz-testcase-minimized-5561715838156800
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This simplifies incoming SDL related changes by removing potential
mismatching states of sdl and sdl2 variables. Since a component can have
all kind of states (such as unset, enabled, disabled or requested),
keeping these variables in sync manually in random places is not robust.
Interlaced encoding profits from it, or might even need it in some
players.
No harm in enabling it unconditionally.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
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.
Main use-case is proxying avio through a foreign I/O layer and a custom
AVIO context, without losing latency and performance characteristics.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Merged from Libav commit 173b56218f.
Before this commit, AVIOContext is to be freed with a plain av_free(),
which prevents us from adding any deeper structure to it.
(cherry picked from commit 99684f3ae7)
Signed-off-by: James Almer <jamrial@gmail.com>
move from dashenc, move DASHTmplId and dash_fill_tmpl_params to
dash.c, they will be used by dash demuxer and dash muxer.
v2 fixed:
1. rename common file from dashcomm.* to dash.*
Suggested-by: Hendrik Leppkes <h.leppkes@gmail.com>
v3 fixed:
1. rename header file pre defined
2. add ff_ prefix for the internal API
Suggested-by: James Almer <jamrial@gmail.com>
Suggested-by: Timo Rothenpieler <timo@rothenpieler.org>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Steven Liu <lq@onvideo.cn>
MP4 files with fragments might have the first moof box that is mentioned
in a fragment index before the first mdat box. Since it is then already
parsed by mov_read_header, we have to make sure that mov_switch_root
will not parse it again when seeking by setting the headers_read flag in
the index. Parsing it a second time would cause the ctts_data array to
receive a second copy of the information from the trun box, leading to
wrong PTS values for the second and following fragments in presence of
B-frames.
Fixes ticket 6560.
Signed-off-by: Daniel Glöckner <daniel-gl@gmx.net>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ctts data in ffmpeg relies on the index entries array to be 1:1
with samples... yet sc->sample_count can be read directly from
the 'stsz' box and index entries are only generated if a chunk
count has been read from 'stco' box.
Ensure that if sc->sample_count > 0, sc->chunk_count is too as
a basic sanity check. Additionally we need to check that after
the index is built we have the right number of entries, so we
also check in mov_read_trun() that sc->sample_count ==
st->nb_index_entries.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If a file does not have a known duration, this leads to the timestamps
starting over for the next file, causing non-monotonic timestamps.
To prevent this, track the duration during demuxing and use it to
determine the current file duration before opening the next file.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Adds FATE tests for the previously untested allrgb, allyuv, rgbtestsrc,
smptebars, smptehdbars and yuvtestsrc filters.
Also adds a test for testsrc2 filter with rgb+alpha.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
This patch makes the libvmaf filter use pkg-config to detect
and link to libvmaf.
Signed-off-by: Ashish Singh <ashk43712@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Hi, it fixes the errors while converting to framesync2.
libvmaf was changed recently, double *score variable is removed in the new
version since it's not used anywhere. This patch fixes all the warnings and
segmentation faults.
Signed-off-by: Ashish Singh <ashk43712@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Windows nvcc + cl.exe produce a .ctx file with CR+LF newlines which
need to be stripped to work with gcc.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Others do not work, but nothing rejects them prior to this patch if the
parameters otherwise match
Reviewed-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Remove usage of FF_MPV_COMMON_OPTS, and set SnowContext.motion_est directly.
Based on code from svq1enc.c
Signed-off-by: James Almer <jamrial@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Change the slice/parameter buffers to be allocated dynamically.
Signed-off-by: Wang, Yi A <yi.a.wang@intel.com>
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
Fixes: runtime error: signed integer overflow: 8903997421129740175 + 354481484684609529 cannot be represented in type 'long'
Fixes: 2045/clusterfuzz-testcase-minimized-6751255865065472
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: loop.m3u
The default max iteration count of 1000 is arbitrary and ideas for a better solution are welcome
Found-by: Xiaohei and Wangchu from Alibaba Security Team
Previous version reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Decklink devices can output 2, 8 or 16 audio channels along video.
The code was limited to 2 or 8 channels. The commit enables 16 audio
channels (relevant for SDI outputs).
Signed-off-by: Marton Balint <cus@passwd.hu>
The -map option allows for a trailing ? so that an error is not thrown if
the input stream does not exist.
This capability is extended to the map_channel option.
This allows a ffmpeg command not to break if an input channel does not
exist, which can be of use (for instance, scripts processing audio
channels with sources having unset number of audio channels).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
JPEGs store embedded profiles under the APP2 marker, signified
with a "ICC_PROFILE" null-terminated string header, and can be
split across multiple APP2 markers, out of order.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
When sidx box support is enabled, the code will skip reading all
trun boxes (each containing ctts entries for samples inthat box).
If seeks are attempted before all ctts values are known, the old
code would dump ctts entries into the wrong location. These are
then used to compute pts values which leads to out of order and
incorrectly timestamped packets.
This patch fixes ctts processing by always using the index returned
by av_add_index_entry() as the ctts_data index. When the index gains
new entries old values are reshuffled as appropriate.
This approach makes sense since the mov demuxer is already relying
on the mapping of AVIndex entries to samples for correct demuxing.
As a result of this all ctts entries are now 1-count. A followup
change will be submitted to remove support for > 1 count entries
which will simplify seeking.
Notes for future improvement:
Probably there are other boxes (stts, stsc, etc) that are impacted
by this issue... this patch only attempts to fix ctts since it
completely breaks packet timestamping.
This patch continues using an array for the ctts data, which is not
the most ideal given the rearrangement that needs to happen (via
memmove as new entries are read in). Ideally AVIndex and the ctts
data would be set-type structures so addition is always worst case
O(lg(n)) instead of the O(n^2) that exists now; this slowdown is
noticeable during seeks.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed integer overflow is undefined behavior.
Detected with clang and -fsanitize=signed-integer-overflow
Signed-off-by: Vitaly Buka <vitalybuka@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed integer overflow is undefined behavior.
Detected with clang and -fsanitize=signed-integer-overflow
Signed-off-by: Vitaly Buka <vitalybuka@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed integer overflow is undefined behavior.
Detected with clang and -fsanitize=signed-integer-overflow
Signed-off-by: Vitaly Buka <vitalybuka@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
this is undocumented in the vp9 bitstream and decoding specification
doc, but matches libvpx
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: James Zern <jzern@google.com>
Use AVCodecContext.compression_level rather than a private option,
replacing the H.264-specific quality option (which stays only for
compatibility).
This now works with the H.265 encoder in the i965 driver, as well as
the existing cases with the H.264 encoder.
(cherry picked from commit 19388a7200)
KB2 'i' found in Life is Strange (Xbox 360), rest verified against binkconv.exe
Signed-off-by: bnnm <bananaman255@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Without this its possible to make the new decode API decode billions of samples
out of a empty input and never return to the caller before all samples have been
created and discarded.
Fixes: Timeout
Fixes: 2992/clusterfuzz-testcase-6649611793989632
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Using named define properly documents the code paths.
It also avoids passing additional numbered arguments through
multiple levels of macro templates.
The suffix handling is done by concatenation, like in
other asm functions and avoid having two separate
"cglobal" defines.
Signed-off-by: Ivan Kalvachev <ikalvachev@gmail.com>
This splits the asm function into exact and non-exact version. The exact
version is as fast or faster on newer CPUs (which EXTERNAL_AVX_FAST describes
well) whilst the non-exact version is faster than the exact on older CPUs.
Also fixes yasm compilation which doesn't accept !cpuflags(avx) syntax.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Improved version of VBROADCASTSS that works like the avx2 instruction.
Emulation of vpbroadcastd.
Horizontal sum HSUMPS that places the result in all elements.
Emulation of blendvps and pblendvb.
Signed-off-by: Ivan Kalvachev <ikalvachev@gmail.com>
Fixes: runtime error: negation of -2147483648 cannot be represented in type 'int32_t' (aka 'int'); cast to an unsigned type to negate this value to itself
Fixes: 2879/clusterfuzz-testcase-minimized-6317542639403008
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When using streaming input, it may be possible to see frames that appear
before the current_frame. When these frames are inserted into the
index, the current_frame needs to be updated so it is still pointing
at the same frame.
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When the background had an alpha channel, the old code in blend_plane
calculated premultiplied alpha from the destination plane colors instead of the
destination alpha.
Also the calculation of the output alpha should only happen after the color
planes are already finished.
Fixes output of:
ffplay -f lavfi "testsrc2=alpha=32[a];color=black[b];[b][a]overlay[out0]"
Signed-off-by: Marton Balint <cus@passwd.hu>
The use of this SEI is for backward compatibility in HLG HDR systems:
older devices that cannot interpret the "arib-std-b67" transfer will
get the compatible transfer (usually bt709 or bt2020) from the VUI,
while newer devices that can interpret HDR will read the SEI and use
its value instead.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
If using the winstore compat library, a fallback LoadLibrary
function does exist, that only calls LoadPackagedLibrary though
(which doesn't work for dynamically loading d3d11 DLLs).
Therefore explicitly check the targeted API family instead.
Make this check a reusable HAVE_* component which other parts
of the libraries can check when necessary as well.
Signed-off-by: Martin Storsjö <martin@martin.st>
Merged from Libav commit 4d330da006.
Black isn't always just memset(ptr, 0, size). Limited YUV in particular
requires relatively non-obvious values, and filling a frame with
repeating 0 bytes is disallowed in some contexts. With component sizes
larger than 8 or packed YUV, this can become relatively complicated. So
having a generic function for this seems helpful.
In order to handle the complex cases in a generic way without destroying
performance, this code attempts to compute a black pixel, and then uses
that value to clear the image data quickly by using a function like
memset.
Common cases like yuv410p10 or rgba can't be handled with a simple
memset, so there is some code to fill memory with 2/4/8 byte patterns.
For the remaining cases, a generic slow fallback is used.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Merged from Libav commit 45df7adc1d.
The pointer to the packet queue is stored in the internal structure
so the queue needs to be flushed before internal is freed.
Signed-off-by: Steven Siloti <ssiloti@bittorrent.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes filter-pixfmts-scale test failing on big-endian systems due to
alpSrc not being cast to (const int32_t**).
Also fixes distortions in the output alpha channel values by copying the
alpha channel code from the rgba64 case found elsewhere in output.c.
Fixes ticket 6555.
Signed-off-by: James Cowgill <James.Cowgill@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The height convention for decoding frames with only a single field made sense
for compatibility with legacy decoders, but doesn't really match the convention
used by NDI, which is the primary (only?) user. Thus, change it to simply
assuming that if the two fields overlap, the frame is meant to be a single
field and the frame height matches the field height.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: runtime error: signed integer overflow: 26215360 + 2121330944 cannot be represented in type 'int'
Fixes: 2809/clusterfuzz-testcase-minimized-4785181833560064
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
This commit switches off forced correct nesting of tags and only keeps
it for font tags. See long explanations in the code for the rationale.
This results in various FATE changes which I'll explain here:
- various swapping in font attributes, this is mostly noise due to the
old reverse stack way of printing them. The new one is more correct as
the last attribute takes over the previous ones.
- unrecognized tags disappears
- invalid tags that were previously displayed aren't anymore (instead,
we have a warning). This is better for the end user
The main benefit of this commit is to be more tolerant to error, leading
to a better handling of badly nested tags or random wrong formatting for
the end user.
With this helper API, filters that used the first framesync
helper API can easily be changed to use the new and more
extensible design for filters with a single activate() callback.
framesync2 will be the base for the version using activate.
Most of the logic will be the same, but the code cannot be shared.
Copying the file initially without change will make the diff
easier to read.
This reverts commit 04aa09c4bc
and reintroduces 0ff5567a30 that
was temporarily reverted due to minor regressions.
It also reverts e5bce8b4ce that fixed FATE refs.
The fate-ffm change is caused by field_order now being set
on the output format because the first frame arrives earlier.
The fate-mxf change is assumed to be the same.
2.5ms frames:
Before (c): 2638 decicycles in postrotate, 2097040 runs, 112 skips
After (sse3): 1467 decicycles in postrotate, 2097083 runs, 69 skips
After (avx2): 1244 decicycles in postrotate, 2097085 runs, 67 skips
5ms frames:
Before (c): 4987 decicycles in postrotate, 1048371 runs, 205 skips
After (sse3): 2644 decicycles in postrotate, 1048509 runs, 67 skips
After (avx2): 2031 decicycles in postrotate, 1048523 runs, 53 skips
10ms frames:
Before (c): 9153 decicycles in postrotate, 523575 runs, 713 skips
After (sse3): 5110 decicycles in postrotate, 523726 runs, 562 skips
After (avx2): 3738 decicycles in postrotate, 524223 runs, 65 skips
20ms frames:
Before (c): 17857 decicycles in postrotate, 261866 runs, 278 skips
After (sse3): 10041 decicycles in postrotate, 261746 runs, 398 skips
After (avx2): 7050 decicycles in postrotate, 262116 runs, 28 skips
Improves total decoding performance for real world content by 9% with avx2.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
ac3dsp.c uses tables from ac3.c
ac3.c uses tables from ac3tab.c
hevc_ps uses tables from hevc_data.c
intrax8.c uses tables from msmpeg4data.c
Signed-off-by: Matt Oliver <protogonoi@gmail.com>
This only enables dlls that are packaged with the application to be
loaded. Due to the limitations of WinRT/UWP it is not allowed to load
external/system dlls so this cannot be used as a complete replacement
for normal win32 dll loading.
Signed-off-by: Matt Oliver <protogonoi@gmail.com>
Fixes: out of array accesses
Found-by: JunDong Xie of Ant-financial Light-Year Security Lab
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array accesses
Fixes: crash-9238fa9e8d4fde3beda1f279626f53812cb001cb-SEGV
Found-by: JunDong Xie of Ant-financial Light-Year Security Lab
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The patch does not fix the tsan warning it was intended to fix.
Reverting the patch moves the av_log() back to the outside of the lock.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
default_ref[] is unconditionally initialized in h264_initialise_ref_list()
(called from ff_h264_build_ref_list(), called from h264_slice_init()).
This fixes the following tsan warning when running fate-h264:
WARNING: ThreadSanitizer: data race (pid=31070)
Write of size 8 at 0x7bbc000082a8 by thread T1 (mutexes: write M1628):
#0 memcpy /work/release-test/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
(ffmpeg+0x10de9d)
#1 h264_initialise_ref_list ffmpeg/libavcodec/h264_refs.c:214:29 (ffmpeg+0x1186b3f)
#2 ff_h264_build_ref_list ffmpeg/libavcodec/h264_refs.c:306 (ffmpeg+0x1186b3f)
#3 h264_slice_init ffmpeg/libavcodec/h264_slice.c:1900:11 (ffmpeg+0x1191149)
[..]
Previous read of size 8 at 0x7bbc000082a8 by main thread (mutexes:
write M1630):
#0 memcpy /work/release-test/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
(ffmpeg+0x10de9d)
#1 ff_h264_update_thread_context ffmpeg/libavcodec/h264_slice.c:411:5 (ffmpeg+0x118b7dc)
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Avoid undefined behavior in skip_input() by checking that enough data is
available before incrementing input pointer.
Check return values of parse_key() and skip_input() and exit early with
error if there is not enough data.
Export the raw data as ICC Profile frame side data.
Reviwed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Print the name metadata entry and the buffer size.
Reviwed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: double free
Fixes: clusterfuzz-testcase-minimized-5080550145785856
Found-by: ClusterFuzz
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Many image formats support embedding of ICC profiles directly in
their bitstreams. Add a new side data type to allow exposing them to
API users.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Fixes: avcodec/aacps.c:511:40: runtime error: signed integer overflow: 1509077651 + 758068176 cannot be represented in type 'int'
Fixes: 2678/clusterfuzz-testcase-minimized-4702787684270080
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ticket-id: #6541
when use hls fmp4 muxer, the extention name is not .m4s, this
code can fix it.
Found-by: JohnPi
Signed-off-by: Steven Liu <lq@onvideo.cn>
That line has been written by previous job.
Fix tsan warning.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
Otherwise the first decoded frame will still be tagged with the
original transfer instead of the alternative one.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Reduced msa load-store code.
Removed inline asm of GP load-store for 64 bit.
Updated variable names in GP load-store macros for naming consistency.
Corrected macro descriptions.
Signed-off-by: Kaustubh Raste <kaustubh.raste@imgtec.com>
Reviewed-by: Manojkumar Bhosale <Manojkumar.Bhosale@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ff_h264_decode_mb_cabac() and ff_h264_decode_mb_cavlc() are very long
functions. Declaring decode_chroma as const makes it clear the variable
doesn't change after initialization.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
hevc_await_progress() uses the variable |y| only inside the "if" block.
So |y| only needs to be declared and initialized in that block.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This file already has #include "idctdsp.h", which is resolved to the
idctdsp.h header in the directory where this file resides by compilers.
Two other files in this directory, libavcodec/x86/idctdsp_init.c and
libavcodec/x86/xvididct_init.c, also rely on #include "idctdsp.h"
working this way.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For the blue and violet noise, I took the pink and brown noise
respectively and subtracted the offsets instead of adding them. When I
eyeball the frequency spectrum of the resulting outputs it looks correct
to me, i.e. the blue graph appears to be a mirror image of the pink, and
the same can be said of the violet and the brown. I did not do anything
else to confirm the correctness.
Also remove pthread_cond_broadcast(progress_cond) on uninit.
Broadcasting it is not required because workers are always
parked when they are not in thread_execute. So it is imposible
that a worker is waiting on progress_cond when uninitialized.
Benchmark:
./ffmpeg -threads $threads -thread_type slice -i 10slices.mp4 -f null null
threads=2:
old: 70.212s 70.525s 70.877s
new: 65.219s 65.377s 65.484s
threads=3:
old: 65.086s 66.306s 66.409s
new: 63.229s 65.026s 65.116s
threads=4:
old: 60.993s 61.482s 62.123s
new: 59.224s 59.441s 59.667s
threads=5:
old: 57.576s 57.860s 58.832s
new: 53.032s 53.948s 54.086s
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
Rework it to improve performance. Now mutex is not shared by workers,
instead each worker has its own mutex and condition variable. This
reduces lock contention between workers. Also use atomic variable for
counter.
The interface also allows execute to run special function on main
thread, requested by Ronald.
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
Muxers may want to directly access filename in stored in
AVFormatContext. For example in case of RTSP, the filename (url)
is used by the muxer to extract parameters of the connection.
These muxers will fail when used with fifo pseudo-muxer.
This commit fixes this issue by passing filename from AVFormatContext
of fifo pseudo-muxer to all AVFormatContext(s) of underlying muxers
during initialization.
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
Avoid using bitstream reader in a non-standard way by directly accessing
index. Use bit shifting/masking operations instead.
Signed-off-by: James Almer <jamrial@gmail.com>
Duration computation can be simplified because number of PCM blocks is
only allowed to be a multiple of 8.
Signed-off-by: James Almer <jamrial@gmail.com>
This makes probing for regular DTS more strict because more header
fields are checked and values not supported by decoder are now rejected.
Also fixes an issue original code had with 14-bit streams: 96 bits of
header were expected, however only 84 bits were converted, which was not
enough to parse LFE flag.
Signed-off-by: James Almer <jamrial@gmail.com>
There are 3 different places where DCA core frame header is parsed:
decoder, parser and demuxer. Each one uses ad-hoc code. Add common core
frame header parsing function that will be used in all places.
Signed-off-by: James Almer <jamrial@gmail.com>
Hardware pixel formats do not tell you anything about their actual
contents, but should still score higher than formats with completely
unknown properties, which in turn should score higher than invalid
formats.
Do not return an AVERROR code as a score.
Fixes a hang in libavfilter where format negotiation gets stuck in a
loop because AV_PIX_FMT_NONE scores more highly than all other
possibilities.
the VAEncSliceParameterBufferHEVC in libva have support this field,
so remove the duplicate field in VAAPIEncodeH265MiscSliceParams.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
This reduces the number of strstr() calls per byte
This diasalows empty tags like '< >' as well as '<' in tags like '<ab<cd<<ef>'
Fixes timeout
Fixes: 1817/clusterfuzz-testcase-minimized-5104230530547712
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
v2:
- use uint16_t instead of int to store 10-bit ancillary data
- fix ancillary line numbers for 1080p
- some comments and clarifications as requested by Aaron Levinson
Signed-off-by: Marton Balint <cus@passwd.hu>
This also add supports for 4K DeckLink cards because they always output the
ancillary data in 10-bit.
v2:
- only try teletext decoding for 576i PAL mode
- some comments as requested by Aaron Levinson
Signed-off-by: Marton Balint <cus@passwd.hu>
This one changes the previous vmaf patch to libvmaf to keep it separate from the
native implementation of vmaf inside ffmpeg later.
Signed-off-by: Ashish Singh <ashk43712@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Fixes: runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: 2634/clusterfuzz-testcase-minimized-4540890636877824
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The pkg-config file is relatively new (2013), so some distros might
not have it yet. And the -lstdc++ being required for the static lib
is only present since the last release in December 2016.
Add the debug_threads boolean field to PerThreadContext. For
PerThreadContext *p, p->debug_threads records whether the
FF_DEBUG_THREADS bit is set in p->avctx->debug, and p->debug_threads and
p->avctx->debug are kept in sync. The debug_threads field is defined as
an atomic_int to allow atomic read by another thread in
ff_thread_await_progress().
This fixes the tsan warning that
2e664b9c1e attempted to fix:
WARNING: ThreadSanitizer: data race (pid=452658)
Write of size 4 at 0x7b640003f4fc by main thread (mutexes: write M248499):
#0 update_context_from_user [..]/libavcodec/pthread_frame.c:335:19 (5ab42bb1a6f4b068d7863dabe9b2bacc+0xe73859)
[..]
Previous read of size 4 at 0x7b640003f4fc by thread T130 (mutexes: write M248502, write M248500):
#0 ff_thread_await_progress [..]/libavcodec/pthread_frame.c:591:26 (5ab42bb1a6f4b068d7863dabe9b2bacc+0xe749a1)
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
The only use of that argument was for Opus downmixing which is very rare
and better done after the mdcts.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
It is redundant with costable. The first half of sintable is
identical with the second half of costable. The second half
of sintable is negative value of the first half of sintable.
The computation is changed to handle sign of sin values, in
C code and ARM assembly code.
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
This mode apparently does not support decoding of HEVC Main (8 bit).
With D3D11 and Intel drivers on Windows 10 I get green corruption, while
using DXVA2_ModeHEVC_VLD_Main works.
In url_find_protocol(), proto_str is either "file" or a string
consisting of only the characters in URL_SCHEME_CHARS, which does not
include ','. Therefore the strchr(proto_str, ',') call always returns
NULL.
Note: The code was added in commit
6161c41817.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
When 'out' is an AVFrame that does not have buffers preallocated,
swr_convert_frame tries to allocate buffers of the right size. However
in calculating this size it failed to check for whether 'in' is NULL
(requesting that swr's internal buffers are to be flushed).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
have not implementation the fmp4 single file yet before this commit.
Suggested-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Steven Liu <lq@onvideo.cn>
libvorbis comes with pkg-config files since at least v1.0.1, way back in 2003.
We need the two checks for vorbis and vorbisenc because we use functions from
both and Xiph considers them separate libraries.
The check is inverted (vorbis first then vorbisenc) because add_extralibs()
prepends to EXTRALIBS instead of appending. For both shared and static linking
the order didn't seem to matter anyway, testing with MinGW.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Some .srt files use this tag.
(An alternative implementation would be correctly ignoring unknown tags,
and treating them as whitespace. libass can do automatic line wrapping.)
Added 2 byte skipping if there no sound present, that fixes playback
files without sound stream.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If AVCodecParameters.codec_tag is 'hvc1' use it instead of 'hev1' for
h.265 streams. QuickTime (and other Apple software) requires 'hvc1'.
(cherry picked from commit 84ab1cc437)
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
mux.c init_muxer() already sets codec_tag correctly in the cases
simplified here.
This also adds the capability to support alternative tags for the
same codec_id.
(cherry picked from commit f6f86f432f)
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This reverts commit 24bb7db403.
noise has to after all be sign extended, not zero extended, on tests
other than checkasm.
Fixes most aac tests broken by the now reverted commit.
when use fmp4 segment type in hls and use codec copy,
there have an error message.
error message:
[mp4 @ 0x25df020] Tag avc1 incompatible with output codec id '28' ([33][0][0][0])
[hls @ 0x2615c80] Some of the provided format options in '(null)' are not recognized
Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
this patch can fix it.
Signed-off-by: Liu Qi <w_liuqi@kingsoft.com>
Signed-off-by: Steven Liu <lq@onvideo.cn>
noise needs to be zero extended and it can be done implicitly as a side effect
in a subsequent instruction.
Signed-off-by: James Almer <jamrial@gmail.com>
ff_mp4_obj_type contains the wrong type of tags for
AVOutputFormat.codec_tag. AVOutputFormat.codec_tag is used to
validate AVCodecParameters.codec_tag so needs to be the same
type of tag.
Creates new tag lists for mp4 and ismv. New tag lists support
same list of codecs found in ff_mp4_obj_type. psp uses the same
tag list as mp4 since these both use mp4_get_codec_tag to look up tags.
(cherry picked from commit 713efb2c0d)
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Skip the codec_tag altogether here, to let the user (try to) set
whichever codec/tag is preferred; the individual chained muxer will
reject invalid codecs anyway.
(cherry picked from commit 61f589e31e)
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
The scale2ref filter will now maintain the DAR of the main input and
not the DAR of the reference input. This previous behavior was deemed
counterintuitive for most (all?) use-cases.
Before:
scale2ref=iw/4:ow/mdar
in w:320 h:240 fmt:rgb24 sar:1/1
ref w:640 h:360 fmt:rgb24 sar:1/1
out w:160 h:120 fmt:rgb24 sar:4/3 flags:0x2
SAR: ((120 * 640) / (160 * 360)) * (1 / 1) = 4 / 3
DAR: (160 / 120) * (4 / 3) = 16 / 9
(main out now same DAR as ref)
Now:
scale2ref=iw/4:ow/mdar
in w:320 h:240 fmt:rgb24 sar:1/1
ref w:640 h:360 fmt:rgb24 sar:1/1
out w:160 h:120 fmt:rgb24 sar:1/1 flags:0x2
SAR: ((120 * 320) / (160 * 240)) * (1 / 1) = 1 / 1
DAR: (160 / 120) * (1 / 1) = 4 / 3
(main out same DAR as main in)
The scale2ref FATE test has also been updated.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Replicates the logic used in the wrap_hw_buffer path to wrap_sw_buffer
as well.
Fixes decoding issues observed on AMLogic devices with
OMX.amlogic.mpeg2.decoder.awesome, where the decoder would spit out a
constant stream of "mPtsRecoveryCount" errors and decoded frames were
returned in the incorrect order.
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
NVIDIA broke its own API when using VDPAU decoding. If you retrieve the
decoded YUV data, or if you map the surfaces with GL interop, the result
are interlacing artifacts. The only way to get non-broken data is by
using the vdpau video mixer to convert it to RGB. There is no way to
block the non-working operations in a reasonable way (a VdpVideoSurface
has to support all operations).
NVIDIA refuses to fix this issue (they "fixed" it by making it work with
the video mixer, but the rest is still broken). There is no sign of that
changing.
Do not use HEVC by default with the generic hwaccle API. Detect whether
it's the NVIDIA native implementation, and exit with an error. (The same
thing work with the MESA implementation.)
As an escape hatch and to allow applications to use the decoder if they
really want to (perhaps because they make sure to explicitly use the
video mixer), reuse AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH to disable
this check.
Once NVIDIA fixes the bug, working driver versions could be detected,
and it could be allowed again.
I noticed this with mastering display data. If frame threading is
enabled, this side data is exported only for some frames. It turns out
it's not properly propagated to the worker threads.
I didn't touch A53 captions, because that involves memory allocation and
freeing the data as side data is exported.
Micro bump so that API users can detect the bug fix.
Otherwise AVTimebaseSource gets av_apply_bitstream_filters' documentation in doxygen.
Signed-off-by: Max Weber <mii7303@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The use of this SEI is for backward compatibility in HLG HDR systems:
older devices that cannot interpret the "arib-std-b67" transfer will
get the compatible transfer (usually bt709 or bt2020) from the VUI,
while newer devices that can interpret HDR will read the SEI and use
its value instead.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This is not needed when the buffer is large enough for the worst case of a line
2% faster vlc reading
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The code originally pre-multiply by 2 the steps, causing the running sum
of the h factors to drift away due to the lack of precision. It quickly
causes an inaccuracy > 0.01.
I tried diverse approaches such as multiply by 2.0 (instead of adding
the value itself) without success.
I'm unable to bench the impact of this change, feel free to compare.
This commit fixes the incoming aacpsdsp tests.
Following is an alternative simplified function (matching the incoming
AArch64 code) that may be used:
function ff_ps_stereo_interpolate_neon, export=1
vld1.32 {q0}, [r2]
vld1.32 {q1}, [r3]
ldr r12, [sp]
vmov.f32 q8, q0
vmov.f32 q9, q1
vzip.32 q8, q0
vzip.32 q9, q1
1:
vld1.32 {d4}, [r0,:64]
vld1.32 {d6}, [r1,:64]
vadd.f32 q8, q8, q9
vadd.f32 q0, q0, q1
vmov.f32 d5, d4
vmov.f32 d7, d6
vmul.f32 q2, q2, q8
vmla.f32 q2, q3, q0
vst1.32 {d4}, [r0,:64]!
vst1.32 {d5}, [r1,:64]!
subs r12, r12, #1
bgt 1b
bx lr
endfunc
Hardware accelerated decoding generally uses AVHWFramesContext for pool
allocation of hardware surfaces. These are setup to allocate surfaces
aligned to hardware and hwaccel API requirements. Due to the
architecture, av_hwframe_get_buffer() will return AVFrames with
the dimensions set to the aligned sizes.
This causes some decoders (like hevc) return these aligned size as
final frame size, instead of cropping them to the video's actual
dimensions. To make sure this doesn't happen, crop the frame to the
size the decoder expects when ff_get_buffer() is called.
Merges Libav commit 3fdf50f9e8.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Some devices (some phones, apparently) will support only this opaque
format. Of course this won't work with CLI, because copying data
directly is not supported.
Automatic frame allocation (setting AVCodecContext.hw_device_ctx) does
not support this mode, even if it's the only supported mode. But since
opaque surfaces are generally less useful, that's probably ok.
Merges Libav commit 5030e3856c.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Makes dealing with formats that can not be used for staging textures
easier (DXGI_FORMAT_420_OPAQUE). It also saves memory if the staging
texture is never needed, so this is a good thing.
Merges Libav commit 98d73e4174.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
It appears in this case, frames_ininit is called twice (once by
av_hwframe_ctx_init(), and again by unreffing the frames ctx ref).
Merges Libav commit 086321c612.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Some existed since forever, some are new.
The cast in get_surface() is silly, but unless we change the av_log
function signature, or all callers of ff_dxva2_get_surface_index(), it's
needed to remove the const warning.
Merges Libav commit 752ddb4556.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Make supported codec profiles part of each dxva_modes entry. Every DXVA2
mode is representative for a codec with a subset of supported profiles,
so reflecting that in dxva_modes seems appropriate.
In practice, this will more strictly check MPEG2 profiles, will stop
relying on the surface format checks for selecting the correct HEVC
profile, and remove the verbose messages for mismatching H264/HEVC
profiles. Instead of the latter, it will now print the more nebulous "No
decoder device for codec found" verbose message.
This also respects AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH. Move the
Main10 HEVC entry before the normal one to make this work better.
Originally inspired by VLC's code.
Merges Libav commit 70e5e7c022.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
When targeting the UWP API subset, the LoadLibrary function is not
available (and the fallback, LoadPackagedLibrary, can't be used to
load system DLLs). In these cases, link directly to the functions
in the DLLs instead of trying to load them dynamically at runtime.
Merges Libav commit fd1ffa1f10.
Signed-off-by: Martin Storsjö <martin@martin.st>
This also adds support to avconv (which is trivial due to the new
hwaccel API being generic enough).
The new decoder setup code in dxva2.c is significantly based on work by
Steve Lhomme <robux4@gmail.com>, but with heavy changes/rewrites.
Merges Libav commit f9e7a2f95a.
Also adds untested VP9 support.
The check for DXVA2 COBJs is removed. Just update your MinGW to
something newer than a 5 year old release.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
I want to make it non-mandatory to set a mutex in the D3D11 device
context, and replacing it with user callbacks seems like the best
solution. This is preparation for it. Also makes the code slightly more
readable.
Merges Libav commit 831cfe10b4.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
The actual hwaccel code will need to access an internal context instead
of avctx->hwaccel_context, so add a new DXVA_CONTEXT() macro, that will
dispatch between the "old" external and the new internal context.
Also, the new API requires a new D3D11 pixfmt, so all places which check
for the pixfmt need to be adjusted. Introduce a ff_dxva2_is_d3d11()
function, which does the check.
Merges Libav commit 4dec101acc.
Adds changes to vp9 over the Libav patch.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
So a hwaccel can access avctx->hwaccel in init for whatever reason. This
is for the new d3d hwaccel API. We could create separate entrypoints for
each of the 3 hwaccel types (dxva2, d3d11va, new d3d11va), but this
seems nicer.
Merges Libav commit bd747b9226.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
To be used with the new d3d11 hwaccel decode API.
With the new hwaccel API, we don't want surfaces to depend on the
decoder (other than the required dimension and format). The old D3D11VA
pixfmt uses ID3D11VideoDecoderOutputView pointers, which include the
decoder configuration, and thus is incompatible with the new hwaccel
API. This patch introduces AV_PIX_FMT_D3D11, which uses ID3D11Texture2D
and an index. It's simpler and compatible with the new hwaccel API.
The introduced hwcontext supports only the new pixfmt.
Frame upload code untested.
Significantly based on work by Steve Lhomme <robux4@gmail.com>, but with
heavy changes/rewrites.
Merges Libav commit fff90422d1.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Yasm:
src/libavfilter/x86/af_volume.asm:24: warning: Standard COFF does not support read-only data sections
src/libavfilter/x86/af_volume.asm:24: warning: Unrecognized qualifier `align'
Nasm:
src/libavfilter/x86/af_volume.asm:24: error: standard COFF does not support section alignment specification
src/libavutil/x86/x86inc.asm:92: ... from macro `SECTION_RODATA' defined here
Tested-by: Clément Bœsch <u@pkh.me>
Signed-off-by: James Almer <jamrial@gmail.com>
This implements the 0x10 frame format for Interplay MVE movies. The
format is a variation on the 0x06 format with some changes. In addition
to the decoding map there's also a skip map. This skip map is used to
determine what 8x8 blocks can change in a particular frame.
This format expects to be able to copy an 8x8 block from before the last
time it was changed. This can be an arbitrary time in the past. In order
to implement this this decoder allocates two additional AVFrames where
actual decoding happens. At the end of a frame decoding changed blocks
are copied to a finished frame based on the skip map.
The skip map's encoding is a little convulted, I'll refer to the code
for details.
Values in the decoding map are the same as in format 0x06.
Signed-off-by: Hein-Pieter van Braam <hp@tmm.cx>
This implements the 0x06 frame format for Interplay MVE movies. The
format is relatively simple. The video data consists of two parts:
16 bits per 8x8 block movement data
a number of 8x8 blocks of pixel data
For each 8x8 block of pixel data the movement data is consulted. There
are 3 possible meanings of the movement data:
* zero : copy the 8x8 block from the pixel data
* negative : copy the 8x8 block from the previous frame from an offset
determined by the actual value of the entry -0xC000.
* positive : copy the 8x8 block from the current frame from an offset
determined by the actual value of the entry -0x4000
Decoding happens in two passes, in the fist pass only new pixeldata is
copied, during the second pass data is copied from the previous and
current frames.
The codec expects that the current frame being decoded to still has the
data from 2 frames ago on it when decoding starts.
Signed-off-by: Hein-Pieter van Braam <hp@tmm.cx>
Interplay MVE can contain up to three different frame formats. They
require different streams of information to render a frame. This patch
changes the IP packet format to prepare for the extra frame formats.
Signed-off-by: Hein-Pieter van Braam <hp@tmm.cx>
Interplay MVE movies have a SEND_BUFFER operation. Only after this
command does the current decoding buffer get displayed. This is required
for the other frame formats. They are fixed-size and can't always encode
a full frame worth of pixeldata.
This code prevents half-finished frames from being emitted.
Signed-off-by: Hein-Pieter van Braam <hp@tmm.cx>
This is actually internal utvideo format.
Allows to make use of SIMD for median prediction for rgb(a) formats,
thus speeding up decoding.
Simplifies code, eases further developement and maintenance.
Update FATE because of pixel format switch.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The result of the call is not used in any testcase but breaks some cases if
its failure is considered.
Fixes regression found by jamrial
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Buffering more than one packet can be a huge performance improvement for
encoding files with small packets (e.g. wav) over SMB/CIFS.
Acked-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>
If flushing is not disabled, then mux.c will signal the end of the packets with
an AVIO_DATA_MARKER_FLUSH_POINT, and aviobuf will be able to decide to flush or
not based on the preferred minimum packet size set by the used protocol.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>
This patch makes aviobuf work more like traditinal file IO, which is how people
think about it.
For example, in the past, aviobuf only flushed buffers until the current buffer
position, even if more data was written to it previously, and a backward seek
was used to reposition the IO context.
From now, aviobuf will keep track of the written data, so no explicit seek will
be required till the end of the buffer, or till the end of file before flushing.
This fixes at least one regression, fate-vsynth3-flv was broken if
flush_packets option was set to false, an explicit seek was removed in
4e3cc4bdd8.
Also from now on, if a forward seek in the write buffer were to cause a gap
between the already written data and the new file position, a flush will
happen.
The must_flush varable is also removed, which might have caused needless
flushes with multiple seeks whithin the write buffer. Since we know the amount
of data written to it, we will know when to flush.
Signed-off-by: Marton Balint <cus@passwd.hu>
Takes a raw input stream containing frames with correct timestamps but
possibly out of order and inserts additional show-existing-frame
packets to correct the ordering.
(cherry picked from commit 34e051d168)
(cherry picked from commit b43b95f478)
Also converted from bitstream to get_bits.
Before this, output bitstream filters would never see EOF and
therefore would not be able to flush any delayed packets.
(cherry picked from commit f64d1100a5)
<@jamrial> durandal_1707: 04aa09c4bc broke fate-lavf-ffm and fate-lavf-mxf
<@durandal_1707> how so?
<@jamrial> one byte changes
<@durandal_1707> jamrial: just update checksums
<@jamrial> durandal_1707: but why did they change at all? the commit you reverted didn't affect them
<@jamrial> why does reverting it affect these tests?
<@jamrial> i don't think updating the checksum without knowing what changed is a good idea
<@durandal_1707> jamrial: the lavfi core is in weird state after removal of recursive code
<@durandal_1707> jamrial: the change is that older ones would get progressive flag set and new one doesnt
<@jamrial> alright
If the first assembler to be probed is an old nasm build, X86ASM_DEPFLAGS
will be set and remain so after yasm is ultimately used as fallback.
This results in yasm being called with said nasm specific flags and failing
during actual object assembly but not with configure sanity checks.
Regression since 5cae5a1def
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
set_ue_golomb just support 2^16 - 2 at most, becase this function call
put_bits, and put_bits just support write up to 31 bits, when write 32
bit in put_bits, it's will overwrite the bit buffer, and the default
assert level is 0, the av_assert2(n <= 31 && value < (1U << n)) in
put_bits can not be trigger runtime.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes a NULL pointer derefence when ogg_init() returns a failure and
a stream's private data was not yet allocated.
This is a regression since 3c5a53cdfa
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This allows for more graceful fallback from NASM to Yasm if the available
NASM version is too old.
(Cherry-picked from libav commit adfd7892e3)
Signed-off-by: James Almer <jamrial@gmail.com>
NASM is more actively maintained and permits generating dependency information
as a sideeffect of assembling, thus cutting build times in half.
(Cherry-picked from libav commit 57b753b445)
Signed-off-by: James Almer <jamrial@gmail.com>
"nasm --version" works on nasm since around version 2.11 and as
such configure assumed it was yasm.
Based on libav commit f54037da8a by
Diego Biurrun.
Signed-off-by: James Almer <jamrial@gmail.com>
Consistently use object format names with "32" suffix and set object format
to "win64" on Windows x86_64, which fixes assembling with nasm.
(Cherry-picked from libav commit 808ef43597)
Signed-off-by: James Almer <jamrial@gmail.com>
This was added in e3e3c82555, probably
as a workaround for the fact that the quant table was not permutated
and the IDCT coefficients are, meaning that you'd only get correct
reconstruction if the IDCT permutation was an identity matrix, which
happens to be the case when you use the simple IDCT. The quant table
permutation bug was fixed in 42dd1434bf,
meaning this workaround is no longer necessary.
In practical terms, before 42dd1434bf,
the PSNR between decodes of the fate-mdec using simple (C) or simplemmx
IDCTs was 35. After 42dd1434bf, it's 90.
Properly use the b.eq form instead of the nonstandard form (which
both gas and newer clang accept though), and expand the register
lists that used a range (which the Xcode 6.2 clang, based on clang
3.5 svn, didn't support).
Signed-off-by: Martin Storsjö <martin@martin.st>
Properly use the b.eq/b.ge forms instead of the nonstandard forms
(which both gas and newer clang accept though), and expand the
register list that used a range (which the Xcode 6.2 clang, based
on clang 3.5 svn, didn't support).
This is cherrypicked from libav commit
a970f9de86.
Signed-off-by: Martin Storsjö <martin@martin.st>
The early check for inconsistent in-source vs out-of-source build
cannot generate a config.log otherwise.
(Cherry-picked from libav commit 0ee78020cd)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: James Almer <jamrial@gmail.com>
Use avci->last_pkt_props to get the side data. Using |pkt| doesn't work
when FF_API_MERGE_SD is set, as the compressed side data is expanded into
|tmp|, leaving the original |pkt| unchanged.
Signed-off-by: James Almer <jamrial@gmail.com>
Use named arguments for the functions so we can remove a define. The
stride/linesize argument is now ptrdiff_t type so we no longer need to
sign extend the register.
It is wrong/incorrect in two aspects:
1. The pixel format is not enough to guarantee that the resulting file
will be any more compatible with media players.
2. Media players not supporting higher profiles are not necessarily
outdated (in fact this is simply an arrogant statement that
libavcodec can handle these particular features).
You could add that there are plenty of other ways to produce widely
incompatible files with ffmpeg, and these don't show any warnings.
What we really want to do here is defaulting to codec profiles that
have wide compatibility, such as main/high for h264. Also, if an
encoder does not accept certain pixfmts, we should automatically
convert them to a pixfmt the encoder can accept. But the existing
message certainly is not appropriate.
It also works for 2 specific encoders only. Extending it for other
cases would result in a lot of special cases, so this is not the
right place.
Use the correct ctxIdxInc calculation for coded_block_flag.
Keep old behavior for old versions of x264 for backward compatibility.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
The input width and height is known at parse time so there's no
reason ow/oh should not be usable when using 0 as the width or
height expression.
Previously in "scale=0:ow" ow would be set to "0" which works,
conveniently, as "scale=0:0" is perfectly valid input but this breaks
down when you do something like "scale=0:ow/4" which one could
reasonably expect to work as well, but does not as ow is 0 not the
real value.
This change handles the 0 case for w/h immediately so the ow/oh
variables work as expected. Consequently, the rest of the code does
not need to handle 0 input. w/h will always be > 0 or < 0.
The second explicit (int) cast ensures that ow/oh appear as integers
as a user might expect when dealing with pixel dimensions.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
According to libavfilter/scale.c, if the width and height are both
less than or equal to 0 then the input size is used for both
dimensions. It does not need to be -1. -1:-1 is the same as 0:0 which
is the same as -10:-42, etc.
if (w < 0 && h < 0)
eval_w = eval_h = 0;
The documentation for the zscale filter has also been updated since the
behavior is identical.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Fixes: runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: 2291/clusterfuzz-testcase-minimized-5538453481586688
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When the hlsenc at BYTERANGE mode, it should not show the warning message:
"Duplicated segment filename detected:"
Reported-by: Marco <marco@worldcast.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
The md5 protocol has no seek support, but some tests use seeks. This changes
the fate tests to actually create the output files and calculate the md5 on the
written files, which also makes the tests independent of the size of the output
buffers and output buffering in general.
A new md5pipe fate test method is also introduced to keep the old functionality
for tests where using a non-seekable output was intentional, and matroska md5
tests are changed to use that.
Signed-off-by: Marton Balint <cus@passwd.hu>
This reduces the worst case from O(n²) to O(n) time
Fixes Timeout
Fixes: 2127/clusterfuzz-testcase-minimized-6595787859427328
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reduces the amount of debugging information of external asm from
uselessly verbose to informative enough.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Reviewed-by: James Darnley <james.darnley@gmail.com>
Fixes: runtime error: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: 2231/clusterfuzz-testcase-minimized-4565181982048256
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Given how incredibly limited the official specifications are (limiting all use
to only the most common broadcasting formats), permit all supported inputs
by default. This makes the encoder more useful.
Each frame is now padded with 0 values if not enough samples are
present, and all frames are guaranteed to have exactly
1 << (venc->log2_blocksize[1] - 1) samples.
Signed-off-by: Tyler Jones <tdjones879@gmail.com>
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Usage of blocksize, window, mode, and mdct indexes are switched from
default 0 to a default of 1 to better align with specs. A flag of 0
should correspond with short windows, a flag of 1 with long.
Signed-off-by: Tyler Jones <tdjones879@gmail.com>
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Audio samples are shifted around when copying from the frame queue so that
analysis can be done without negatively impacting calculation of the MDCT.
Window coefficients are applied to the current two overlapped windows
simultaneously instead of applying overlap for the next frame ahead of time.
This improves readability when applying windows of varying lengths.
Signed-off-by: Tyler Jones <tdjones879@gmail.com>
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Meant for DSP functions returning a float or double, as they'd fail if emms
is called after every run on x86_32.
Signed-off-by: James Almer <jamrial@gmail.com>
This is something of a hack. It allocates a new hwframe context for
the target format, then maps it back to the source link and overwrites
the input link hw_frames_ctx so that the previous filter will receive
the frames we want from ff_get_video_buffer(). It may fail if
the previous filter imposes any additional constraints on the frames
it wants to use as output.
(cherry picked from commit 81a4cb8e58)
Use the flags argument of av_hwframe_ctx_create_derived() to pass the
mapping flags which will be used on allocation. Also, set the format
and hardware context on the allocated frame automatically - the user
should not be required to do this themselves.
(cherry picked from commit c5714b51aa)
Some frames contexts are not usable without additional format-specific
state in hwctx. This change adds new functions frames_derive_from and
frames_derive_to to initialise this state appropriately when deriving
a frames context which will require it to be set.
(cherry picked from commit 27978155bc)
This only supports one device globally, but more can be used by
passing them with input streams in hw_frames_ctx or by deriving new
devices inside a filter graph with hwmap.
(cherry picked from commit e669db7610)
The non-H.26[45] codecs already use this form. Since we don't
currently generate I frames for codecs which support them separately
to IDR, the p_per_i variable is set to infinity by default so that it
doesn't interfere with any other calculation. (All the code for I
frames still exists, and it works for H.264 if set manually.)
(cherry picked from commit 6af014f402)
In order to work correctly with the i965 driver, this also fixes the
direction of forward/backward references - forward references are
intended to be those from the past to the current frame, not from the
current frame to the future.
(cherry picked from commit 9aa251c98c)
Adds functions to convert to/from strings and a function to iterate
over all supported device types. Also adds a new invalid type
AV_HWDEVICE_TYPE_NONE, which acts as a sentinel value.
(cherry picked from commit b7487f4f3c)
Previously this was leaking, though it actually hit an assert making
sure that the buffer had already been cleared when freeing the picture.
(cherry picked from commit 17aeee5832)
The driver is somewhat bitrotten (not updated for years) but is still
usable for decoding with this change. To support it, this adds a new
driver quirk to indicate no support at all for surface attributes.
Based on a patch by wm4 <nfxjfg@googlemail.com>.
(cherry picked from commit e791b915c7)
Fixes: 1735/clusterfuzz-testcase-minimized-5350472347025408
This uses unsigned instead of SUINT because the later was rejected by multiple developers
See: [FFmpeg-devel] [PATCH] avcodec/fft_template: Fix multiple runtime error: signed integer overflow: -1943918714 - 1935113003 cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If the videos starts with B frame, then the minimum composition time
as computed by stts + ctts will be non-zero. Hence we need to shift
the DTS, so that the first pts is zero. This was the intention of that
code-block. However it was subtracting by the wrong amount.
For example, for one of the videos in the bug nonFormatted.mp4 we have
stts:
sample_count duration
960 1001
ctts:
sample_count duration
1 3003
2 0
1 3003
....
The resulting composition times are : 3003, 1001, 2002, 6006, ...
The minimum composition time or PTS is 1001, which should be used to
offset DTS. However the code block was wrongly using ctts[0] which is
3003. Hence the PTS was negative. This change computes the minimum pts
encountered while fixing the index, and then subtracts it from all the
timestamps after the edit list fixes are applied.
Samples files available from:
https://bugs.chromium.org/p/chromium/issues/detail?id=721451https://bugs.chromium.org/p/chromium/issues/detail?id=723537
fate-suite/h264/twofields_packet.mp4 is a similar file starting with 2
B frames. Before this change the PTS of first two B-frames was -6006
and -3003, and I am guessing one of them got dropped when being decoded
and remuxed to the framecrc before, and now it is not being dropped.
Signed-off-by: Sasi Inguva <isasi@google.com>
Due to a peculiarity in the ModR/M addressing encoding, the r12 and r13
registers sometimes requires an additional byte when used as a base register.
r14 and r15 doesn't have that issue, so prefer using them.
We overload the `call` instruction with a macro, but it would misbehave when
the macro argument wasn't a valid identifier. Fix it by explicitly checking
if the argument is an identifier.
Switches temporary samples for processing to be stored in the encoder's
context, avoids memory leaks if any errors occur while encoding a frame.
Fixes CID1412026
Signed-off-by: Tyler Jones <tdjones879@gmail.com>
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This test the demuxer discarding non ADTS frames at the beginning and
end of the input.
As a side effect, this commit also enables fate-adts-demux, which was
accidentally disabled in 324f0fbff1.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This API is more up-to-date, provides names compatible with filters
and external encoders, and is consistent with the other color
property variables.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Switching the vorbis encoder to use a buffer queue for input frames allows
saving lookahead samples more easily and safely for psychoacoustic systems,
requiring less pointer arithmetic in the case of transient windows.
This reduces the attack surface of local file-system
information leaking.
It prevents the existing exploit leading to an information leak. As
well as similar hypothetical attacks.
Leaks of information from files and symlinks ending in common multimedia extensions
are still possible. But files with sensitive information like private keys and passwords
generally do not use common multimedia filename extensions.
It does not stop leaks via remote addresses in the LAN.
The existing exploit depends on a specific decoder as well.
It does appear though that the exploit should be possible with any decoder.
The problem is that as long as sensitive information gets into the decoder,
the output of the decoder becomes sensitive as well.
The only obvious solution is to prevent access to sensitive information. Or to
disable hls or possibly some of its feature. More complex solutions like
checking the path to limit access to only subdirectories of the hls path may
work as an alternative. But such solutions are fragile and tricky to implement
portably and would not stop every possible attack nor would they work with all
valid hls files.
Developers have expressed their dislike / objected to disabling hls by default as well
as disabling hls with local files. There also where objections against restricting
remote url file extensions. This here is a less robust but also lower
inconvenience solution.
It can be applied stand alone or together with other solutions.
limiting the check to local files was suggested by nevcairiel
This recommits the security fix without the author name joke which was
originally requested by Nicolas.
Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: Thierry Foucu <tfoucu@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reduces the attack surface of local file-system
information leaking.
It prevents the existing exploit leading to an information leak. As
well as similar hypothetical attacks.
Leaks of information from files and symlinks ending in common multimedia extensions
are still possible. But files with sensitive information like private keys and passwords
generally do not use common multimedia filename extensions.
It does not stop leaks via remote addresses in the LAN.
The existing exploit depends on a specific decoder as well.
It does appear though that the exploit should be possible with any decoder.
The problem is that as long as sensitive information gets into the decoder,
the output of the decoder becomes sensitive as well.
The only obvious solution is to prevent access to sensitive information. Or to
disable hls or possibly some of its feature. More complex solutions like
checking the path to limit access to only subdirectories of the hls path may
work as an alternative. But such solutions are fragile and tricky to implement
portably and would not stop every possible attack nor would they work with all
valid hls files.
Developers have expressed their dislike / objected to disabling hls by default as well
as disabling hls with local files. There also where objections against restricting
remote url file extensions. This here is a less robust but also lower
inconvenience solution.
It can be applied stand alone or together with other solutions.
limiting the check to local files was suggested by nevcairiel
Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: Thierry Foucu <tfoucu@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This new FATE test for the scale2ref filter makes use of the recently
added scale2ref-specific variables to maintain the aspect ratio of a
test input.
Filtergraph explanation:
[main] has an AR of 4:3. [ref] has an AR of 16:9.
640 / 4 = 160. So the new width for [main] is 160.
160 / ((320 / 240) * (1 / 1)) = 160 / (4 / 3) = 120. So the new
height for [main] is 120.
160 / 120 = 4 / 3 so [main]'s aspect ratio has been maintained while
using [ref]'s width as a reference point.
[ref] is nullsink'd since it is left unchanged by scale2ref (and so
shouldn't need to be tested).
If we were to use "iw/4:-1" in place of "iw/4:ow/mdar":
640 / 4 = 160. So the new width for [main] would be 160.
360 / 4 = 90. So the new height for [main] would be 90.
160 / 90 = 16 / 9 so [main] now has the same aspect ratio as [ref]
which is probably what you do not want.
This is currently the only test for scale2ref.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The RGB555 PACKBITSRGN case tries to read a palette, if such
palette is actually stored then it accesses a null pointer.
All 16bit samples i could find use DIRECTBITSRGN.
Fixes: 2065/clusterfuzz-testcase-minimized-6298930457346048
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This also increases the range of input values supported as well as
decreasing the operation dependencies in the main loop, improving
speed on modern CPUs.
Fixes part of: 2045/clusterfuzz-testcase-minimized-6751255865065472
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Atempt to read and propagate only full ADTS frames and not other data,
like id3v1 or APETags at the end of the file.
Fixes ticket #6437.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This reorders the operations so as to avoid computations with the above arguments
before they have been initialized.
Fixes part of 1708/clusterfuzz-testcase-minimized-5035111957397504
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The loglevel is choosen so that the main filename and any images of
multi image sequences are shown only at debug level to avoid
clutter.
This makes exploits in playlists more visible. As they would show
accesses to private/sensitive files
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ff_scale_eval_dimensions blindly assumes that two inputs are always
available as of 3385989b98. This is
notably not the case when the function is called for the scale
filter. With the scale filter inputs[1] does not exist.
ff_scale_eval_dimensions now has an updated scale2ref check that
makes certain two inputs are actually available before attempting to
access the second one.
Thanks to James Almer for reporting this bug. This should fix the 820
Valgrind tests I single-handedly managed to break.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The current upstreamed code has been written and tested for Little Endian systems.
We do have plans to add the Big Endian support in near future, but till that time, need to disable all to avoid its usage and failures.
Signed-off-by: Shivraj Patil <shivraj.patil@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
hw accelerated transcode (h264_cuvid -> h264_nvenc with -hwaccel cuvid) was
broken after the filtergraph initialization was changed to intialize decoder
first followed by encoder (commit af1761f7b5).
During initialzing encoder with bframes, local buffers are allocated
internally in encoder which fails since no cuda context is available. Now
pushing the correct cuda context before encoder initialization fixes the issue.
Also adding push/pop cuda ctx during create/destroy/map/unmap resources and
destroy encoder session.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Variables pertaining to the main video are now available when
using the scale2ref filter. This allows, as an example, scaling a
video with another as a reference point while maintaining the
original aspect ratio of the primary/non-reference video.
Consider the following graph: scale2ref=iw/6:-1 [main][ref]
This will scale [main] to 1/6 the width of [ref] while maintaining
the aspect ratio. This works well when the AR of [ref] is equal to
the AR of [main] only. What the above filter really does is
maintain the AR of [ref] when scaling [main]. So in all non-same-AR
situations [main] will appear stretched or compressed to conform to
the same AR of the reference video. Without doing this calculation
externally there is no way to scale in reference to another input
while maintaining AR in libavfilter.
To make this possible, we introduce eight new constants to be used
in the w and h expressions only in the scale2ref filter:
* main_w/main_h: width/height of the main input video
* main_a: aspect ratio of the main input video
* main_sar: sample aspect ratio of the main input video
* main_dar: display aspect ratio of the main input video
* main_hsub/main_vsub: horiz/vert chroma subsample vals of main
* mdar: a shorthand alias of main_dar
Of course, not all of these constants are needed for maintaining the
AR, but adding additional constants in line of what is available for
in/out allows for other scaling possibilities I have not imagined.
So to now scale a video to 1/6 the size of another video using the
width and maintaining its own aspect ratio you can do this:
scale2ref=iw/6:ow/mdar [main][ref]
This is ideal for picture-in-picture configurations where you could
have a square or 4:3 video overlaid on a corner of a larger 16:9
feed all while keeping the scaled video in the corner at its correct
aspect ratio and always the same size relative to the larger video.
I've tried to re-use as much code as possible. I could not find a way
to avoid duplication of the var_names array. It must now be kept in
sync with the other (the normal one and the scale2ref one) for
everything to work which does not seem ideal. For every new variable
introduced/removed into/from the normal scale filter one must be
added/removed to/from the scale2ref version. Suggestions on how to
avoid var_names duplication are welcome.
var_values has been increased to always be large enough for the
additional scale2ref variables. I do not forsee this being a problem
as the names variable will always be the correct size. From my
understanding of av_expr_parse_and_eval it will stop processing
variables when it runs out of names even though there may be
additional (potentially uninitialized) entries in the values array.
The ideal solution here would be using a variable-length array but
that is unsupported in C90.
This patch does not remove any functionality and is strictly a
feature patch. There are no API changes. Behavior does not change for
any previously valid inputs.
The applicable documentation has also been updated.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
AVCodecContext::refs is used to control the DPB size to be used by the
encoder. The default value for AVCodecContext::refs as set in
libavcodec/options_table.h is 1.
This patch sets AVCodecContext::refs to 0 for h264_nvenc and hevc_nvenc in
order to let the driver take the decision of the correct DPB size to use in
all cases.
Signed-off-by: Srinath K R <skr@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This was actually broken when committed in 46e3936fb04; the
test never succeeded, and thus, _aligned_malloc wasn't actually
used on legacy mingw.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 427f7a1f9e)
With the new decode API, you can't handle errors directly in the API
user - you only know that the hwaccel did not initialize at all.
Add some approximate logging.
This prevents part of one exploit leading to an information leak
Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: Thierry Foucu <tfoucu@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The library has stopped being developed and Debian has removed it
from its repositories citing security issues.
The native Dirac decoder supports everything the library has and basic
encoding support is still provided via the native vc2 (Dirac Pro, intra
only version of Dirac) encoder. Hence, there's no reason to still support
linking to the library and potentially leading users into security issues.
the timeDataSize argument to aacDecoder_DecodeFrame() seems undocumented and until
2016 04 (203e3f28fbebec7011342017fafc2a0bda0ce530) unused.
after that commit libfdk-aacdec interprets it as size in sample units and memsets that on error.
FFmpeg as well as others (like GStreamer) did interpret it as size in bytes
Fixes: 1442/clusterfuzz-testcase-minimized-4540199973421056 (This requires recent libfdk to reproduce)
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
instead of deciding whether to encrypt based on the encryption scheme,
decide according to whether cenc was initialized or not.
mov_create_timecode_track calls ff_mov_write_packet with a track that
doesn't have cenc initialized.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This merges commit 1202b71269 from libav,
originally written by Anton Khirnov and skipped in
fc63d5ceb3.
libavcodec/vp3.c | 26 +++++++++-----------------
1 file changed, 9 insertions(+), 17 deletions(-)
This merges commit 4fded0480f from libav,
originally written by Anton Khirnov and skipped in
fc63d5ceb3.
libavcodec/h264_slice.c | 20 +++++++++++++-------
libavcodec/h264dec.c | 3 +++
libavcodec/h264dec.h | 5 +++++
3 files changed, 21 insertions(+), 7 deletions(-)
These variables are shared between frame threads, but they are updated
post-setup_finished() if a EOB/EOS slice type occurs. Moving the EOB/EOS
slices to the next frame thread instance (by parsing them leading into
the next picture instead of trailing behind the last picture) effectively
prevents this race condition.
This fixes tsan failures on hevc-conformance-NoOutPrior_A_Qualcomm_1.
This removes the current API violating behavior of overwritting the stream's
extradata during packet filtering, something that should not happen after the
av_bsf_init() call.
The bitstream filter generated extradata is no longer available during
write_header(), and as such not usable with non seekable output. The FATE
tests are updated to reflect this.
Signed-off-by: James Almer <jamrial@gmail.com>
This adapts and merges commit f4bf236338
from libav, originally skipped in 13a211e632
as it was not necessary back then.
Is's applied now in preparation for the following patches, where the
aac_adtstoasc bitstream filter will start to correctly propagate the new
extradata through packet side data.
Signed-off-by: James Almer <jamrial@gmail.com>
Don't just look at zero sized packets, and also check for AAC extradata
updates, in preparation for the following patches.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
If the source is using a custom IO, setting this flag causes heavy leaks
since the segments will not have their avio context closed.
Regression since f5da453b06.
Using AVOnce as a stack variable makes no sense as the state is lost
when the function exits.
This fixes repeated calls to av(filter/device)_register_all
Fixes multiple: runtime error: signed integer overflow: 2147115008 + 413696 cannot be represented in type 'int'
Fixes: 1723/clusterfuzz-testcase-minimized-5309409372667904
Fixes: 1727/clusterfuzz-testcase-minimized-5900685306494976
Fixes: 1737/clusterfuzz-testcase-minimized-5922321338466304
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Modifying data pointer when skipping samples may make it unaligned.
Workaround for Ticket6349.
This should fix the crash of ticket's testcase and a crash/regression
with avxsynth (reported by Michael Niedermayer).
Also change frame->nb_samples < max to frame->nb_samples <= max.
This improves performance. Benchmark:
./ffmpeg -filter_complex "aevalsrc=0:n=1166,firequalizer=fixed=on" -f null null
old:
25767 decicycles in take_samples, 1023 runs, 1 skips
25422 decicycles in take_samples, 2047 runs, 1 skips
25181 decicycles in take_samples, 4095 runs, 1 skips
24904 decicycles in take_samples, 8191 runs, 1 skips
new:
550 decicycles in take_samples, 1024 runs, 0 skips
548 decicycles in take_samples, 2048 runs, 0 skips
545 decicycles in take_samples, 4096 runs, 0 skips
544 decicycles in take_samples, 8192 runs, 0 skips
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
Fixes: runtime error: left shift of 706 by 22 places cannot be represented in type 'int'
See: L_shl() in the reference software
Fixes: 1609/clusterfuzz-testcase-minimized-5102163007111168
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '1920382aa9f21d7ed1a3c2214990da8d2b067a92':
dashenc: add option to provide UTC timing source
Also use E instead of AV_OPT_FLAG_ENCODING_PARAM to be consistent with
the other AVOption.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '78489822074096e3ae0f3c3b70accace955086f6':
configure: Place all temporary files in one separate directory
Merged-by: Clément Bœsch <u@pkh.me>
* commit '11e225db31dcad57e2219ad8dfae2ac027af53d6':
rtmp: Account for bytes_read wraparound
This commit is a noop, see 0849a0ebb2
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'ca6ae3b77a7e6600e517723b90e57527a47809de':
vaapi_encode: Add MPEG-2 support
This commit is a noop, see 3b95c7c17d
Merged-by: Clément Bœsch <u@pkh.me>
* commit '95f1004bdfdf2d26c330c1d4b7c4ac9352d60b18':
dashenc: add mandatory id to AdaptationSet and Period in manifest
Merged-by: Clément Bœsch <u@pkh.me>
* commit '2bbb5abd877104fa9bc342c521bb49bc1aad50ce':
build: Map -Wall compiler flag to -W3 for MSVC and -Wextra to -W4
Merged-by: Clément Bœsch <u@pkh.me>
* commit '6151e9128ce2a84a443c82b78f5b5cb364ba2ab4':
build: Detect blocks C language extension and add it as VDA dependency
Merged-by: Clément Bœsch <u@pkh.me>
Some samples have their metadata track time_scale incorrectly set to 0
and the check introduced by a398f054fd
prevents playback of those samples. Setting the time_scale to 1 fixes
playback.
See http://lists.ffmpeg.org/pipermail/ffmpeg-user/2017-April/035975.html
Parsed_filter_X could remain and user can override it with custom one.
Example:
ffplay -f lavfi "nullsrc=s=640x360,
sendcmd='1 drawtext@top reinit text=Hello; 2 drawtext@bottom reinit text=World',
drawtext@top=x=16:y=16:fontsize=20:fontcolor=Red:text='',
drawtext@bottom=x=16:y=340:fontsize=16:fontcolor=Blue:text=''"
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
* commit '562ef82d6a7f96f6b9da1219a5aaf7d9d7056f1b':
fifo: Return the correct AVERROR value
This commit is a noop, see 2e81bb5e92
Merged-by: Clément Bœsch <u@pkh.me>
* commit '381a4e31a6b801a046e38b0e2b08fb61499157a7':
tak: Convert to the new bitstream reader
magicyuv: Convert to the new bitstream reader
truemotion2rt: Convert to the new bitstream reader
wavpack: Convert to the new bitstream reader
mpc: Convert to the new bitstream reader
This merge is a noop, see
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5c0e2b13eb79b455b15355d64f7993b0f66ea9ec':
swscale-test: const correctness for pointer variable
This commit is a noop, see b36745339d
Merged-by: Clément Bœsch <u@pkh.me>
* commit '00b775dda2b3f78ae60ff3278d3b3d6545883a83':
hevc: Mark as having threadsafe init
This commit is a noop, see 14b9060160
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'fb59f87ce72035b940c3f5045884098b9324e1b2':
nvenc: Explicitly push the cuda context on encoding
This commit is a noop, see be74ba648c
Merged-by: Clément Bœsch <u@pkh.me>
* commit '4795e4f61f993940c5384044caff56cc15078698':
alac: Convert to the new bitstream reader
rtp: Convert to the new bitstream reader
mov: Convert to the new bitstream reader
This merge is a noop, see
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html
Merged-by: Clément Bœsch <u@pkh.me>
* commit '44129e38047b6a27291e487c2084894958c6f399':
avconv: Do not pass NULL to avio_tell
This commit is a noop. The FFmpeg code handle cases where total_size is
an AVERROR (which avio_tell(NULL) will return) later in the function.
Note: the original commit refers to the null *muxer*. `ffmpeg -lavfi
testsrc -f null -` can be used as a test case.
Merged-by: Clément Bœsch <u@pkh.me>
It's not used by anything, has dubious usefulness, the reasons for which
it was introduced are no longer valid, and only serves to add complexity
to the build system.
Signed-off-by: James Almer <jamrial@gmail.com>
* commit 'f8f7ad758d0e1f36915467567f4d75541d98c12f':
qsv: Set the correct range for la_depth
This commit is a noop. There is a separate parameter to enable
lookahead, so overloading the depth is unnecessary.
Merged-by: Mark Thompson <sw@jkqxz.net>
Add dxva2_pool_release_dummy() and use it in call to
av_buffer_create() in dxva2_pool_alloc().
Prior to this change, av_buffer_create() was called with NULL for the
third argument, which indicates that av_buffer_default_free() should
be used to free the buffer's data. Eventually, it gets to
buffer_pool_free() and calls buf->free() on a surface object (which is
av_buffer_default_free()).
This can result in a crash when the debug version of the C-runtime is
used on Windows. While it doesn't appear to result in a crash when
the release version of the C-runtime is used on Windows, it likely
results in memory corruption, since av_free() is being called on
memory that was allocated using
IDirectXVideoAccelerationService::CreateSurface().
Signed-off-by: Aaron Levinson <alevinsn@aracnet.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Enables rendering of SVG images. This is possible since SVG images
still contain and specify the dimensions in pixels to which they've
been drawn to and thus enable browsers to display them without any
external data. Users can still override and generate images with
arbitrary resolutions.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Only checks the extension and MIME type, since determining whether
a file is SVG is difficult since they're just XML files.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Old behaviour - abort if at least one subband has 1bit quantizer
and consumed_bits still greater than frame_bits size. It was
a bit strange - we still could reduce bits consumption by reducing
SNR for other subbands. Same strange logic with upper threshold -
stop bits allocation if at least one subband reach 26bits.
New behaviour - if consumed_bits greater than frame_bits and all
subbands has 1 bit quantizer we restart bits allocation and allow
zero subbands.
This brings our generation of the vpcC box up to date to version 1.0
of the VP Codec ISO Media File Format Binding.
Specifically, color/transfer properties are now written with values
based on ISO/IEC 23001-8, which is the same reference specification the
AVColor* enumerations are based on.
This adds tons of code for no other benefit than making VideoToolbox
support conform with the new hwaccel API (using hw_device_ctx and
hw_frames_ctx).
Since VideoToolbox decoding does not actually require the user to
allocate frames, the new code does mostly nothing.
One benefit is that ffmpeg_videotoolbox.c can be dropped once generic
hwaccel support for ffmpeg.c is merged from Libav.
Does not consider VDA or VideoToolbox encoding.
Fun fact: the frame transfer functions are copied from vaapi, as the
mapping makes copying generic boilerplate. Mapping itself is not
exported by the VT code, because I don't know how to test.
reorder_pixels is call by rle_uncompress and zip_uncompress
with size == uncompress_size
uncompress_size is a multiple of 2 (because exr store data
in half, float, or uint32)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Most of these were found through code review in response to
fixing 1466/clusterfuzz-testcase-minimized-5961584419536896
There is thus no testcase for most of this.
The initial issue was Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It was never meant to do otherwise, as av_packet_get_side_data() returns the first
entry it finds of a given type.
Based on code from libavformat's av_stream_add_side_data().
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '1202b712690c14f0efb06e4ad8b06c5b3df6822a':
theora: export cropping information instead of handling it internally
h264dec: export cropping information instead of handling it internally
h264dec: be more explicit in handling container cropping
hevcdec: export cropping information instead of handling it internally
This commit is a noop.
This changes the cropping behavior, when it's supposedly only meant to move
it outside of the decoder.
See https://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/211239.html for the
discussion about it.
Merged-by: James Almer <jamrial@gmail.com>
Separates macro arguments with commas and passes .4H/.8H as macro
arguments instead of 4H/8H (the later form being interpreted as an
hexadecimal value).
Fixes ticket #6324.
Suggested-by: Martin Storsjö <martin@martin.st>
The code was skipping the entire reported SEI message size regardless of
the amount of bits read.
While in theory safe for NALU where the picture timing SEI message is alone
or at the end as we're using the checked bitstream reader, it isn't in any
other situation, where every SEI message in the NALU after the picture
timing one would potentially fail to parse.
Change the function name to one more in line with the rest of file, and
remove the bogus "Skipped SEI" debug message while at it.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
add a per-stream option for setting the encoder timebase.
the following values are allowed:
0 - for video, use 1/frame_rate, for audio use 1/sample_rate (this is
the default)
-1 - match the input timebase (when possible)
>0 - set the timebase to provided number
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ff_accept can return AVERROR(ETIMEDOUT) and errno will be 0 (or
undefined), return ret instead and return ff_neterror() in
ff_poll_interrupt instead of AVERROR(errno) to parse WSAGetLastError on
Windows.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This raises the required minimum NVIDIA display driver versions:
NVIDIA Linux display driver 378.13 or newer
NVIDIA Windows display driver 378.66 or newer
This raises the required minimum NVIDIA display driver versions:
NVIDIA Linux display driver 378.13 or newer
NVIDIA Windows display driver 378.66 or newer
Purpose: Added require alternative for libmfx in the case that pkg-config
cannot find libmfx. On Linux, most people likely get libmfx via
https://github.com/lu-zero/mfx_dispatch , but on Windows, the most
well-known way to get libmfx is via the Intel Media SDK, which
provides a static build of libmfx.lib and also provides the source
code for building libmfx yourself. If built this way, there are no
pkg-config files to be found.
Comments:
-- configure: Altered enabled libmfx step to use use_pkg_config()
instead of require_pkg_config(), and, if use_pkg_config() fails, it
falls back to require(). Also added explanatory comment. Note
that the reason that require() is passed -llibmfx as the last
argument, instead of -lmfx, is the file name for the library
produced from the Intel Media SDK starts with "libmfx".
Apparently, the filename for the library produced via
https://github.com/lu-zero/mfx_dispatch starts with "mfx".
Signed-off-by: Aaron Levinson <alevinsn@aracnet.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Purpose: qsvenc: make sure that interlaced encoding works. Also,
reduce the vertical alignment constraint when possible to reduce
memory usage.
Note: Most of this code used to be present in ffmpeg and was
eliminated in revision 1f26a23 on Oct. 31, 2016 (qsv: Merge libav
implementation, at
https://github.com/FFmpeg/FFmpeg/commit/1f26a231bb065276cd80ce02957c759f3197
edfa#diff-7d84a34d58597bb7aa4b8239dca1f9f8). Already applied to
libav.
Reviewed-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 8fd8f91e47)
Signed-off-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Aaron Levinson <alevinsn@aracnet.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Purpose: Fill out the default/unset parameters with ones actually in use.
Note: Matches the current MediaSDK example code. This code used to be
present in ffmpeg and was eliminated in revision 1f26a23 on Oct. 31,
2016 (qsv: Merge libav implementation, at
1f26a231bb (diff-7d84a34d58597bb7aa4b8239dca1f9f8)).
Already applied to libav.
Reviewed-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit b22094d749)
Signed-off-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Aaron Levinson <alevinsn@aracnet.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Purpose: Made minor changes to get the decklink avdevice code to build
using Visual C++.
Notes: Made changes to configure per Hendrik Leppkes's review of first
and second versions of patch. Also made slight alterations per Marton
Balint's reviews.
Comments:
-- configure: Added if enabled decklink section and setting
decklink_indev_extralibs and decklink_outdev_extralibs here for
both mingw and Windows. Also eliminated the setting of these
variables in the mingw section earlier in the file.
-- libavdevice/decklink_common.cpp: Switched the order of the include
of libavformat/internal.h to workaround build issues with Visual
C++. See comment in file for more details.
-- libavdevice/decklink_dec.cpp:
a) Rearranged the include of libavformat/internal.h (for reasons as
described above).
b) Made slight alteration to an argument for call to av_rescale_q() to
workaround a compiler error with Visual C++. This appears to only
be an issue when building C++ files with Visual C++. See comment
in code for more details.
-- libavdevice/decklink_enc.cpp: Rearranged the include of
libavformat/internal.h (for reasons as described above).
Signed-off-by: Aaron Levinson <alevinsn@aracnet.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
* commit '019ab88a95cb31b698506d90e8ce56695a7f1cc5':
lavc: add an option for exporting cropping information to the caller
Merged-by: James Almer <jamrial@gmail.com>
Replicates lavf/librtmp.c behavior in L149-156 and rtmpdump's
behavior with "--swfVfy <url>" passing the url to swfUrl.
Fixes trac ticket #5549.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
They may be available in hvcc style extradata.
Based on a patch by Hendrik Leppkes.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Aaron Levinson <alevinsn@aracnet.com>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit 'ac3c3ee678e51b05a2a7c30ce79465db46ba01fa':
dxva2: allow an empty array of ID3D11VideoDecoderOutputView
This commit is a noop, see 8fb4865901
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'f67235a28cef44fcd97ae74ad53bbbc0d7f63d60':
dxva2: get the slice number directly from the surface in D3D11VA
This commit is a noop, see 153b36fc62
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '2a2889e130fee6d3c11e506328388afb317626ed':
build: Remove stray duplicate conditional variable declaration
This commit is a noop, there is no duplicate in FFmpeg. we have the
tools rules kept in the root Makefile though (see
802d94c36e)
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '89725a8512721fffd190021ded2d3f5b42e20e2a':
vaapi_h264: Scale log2_max_pic_order_cnt_lsb with max_b_frames
This commit is a noop, see eefa4b76ee
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'a3c3a5eac20a51d402c332cdf5220fff40a7943f':
vaapi_encode: Support forcing IDR frames via AVFrame.pict_type
This commit is a noop, see c667c0979c
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '37fab0661a760b2a9d727939d72e629acee1a6ef':
vaapi_encode: Fix GOP sizing
This commit is a noop, see 760f1a7727
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'bd6496fa07e32fd09ceb79404f9af43df959bcb2':
interplayvideo: Convert to the new bitstream reader
adx: Convert to the new bitstream reader
dvbsubdec: Convert to the new bitstream reader
motionpixels: Convert to the new bitstream reader
This merge is a noop, see
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e435beb1ea5380a90774dbf51fdc8c941e486551':
crypto: consistently use size_t as type for length parameters
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'e7de05f98f630b5b3a5e441c8fa763e6d89b8851':
h264dec: drop a redundant check
This commit is a noop, see 4cc1ce4a91
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '3cba1ad76d362c994fa98fb686e04e20826fb579':
x86inc: Avoid using eax/rax for storing the stack pointer
This commit is a noop, see cd09e3b349
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '4e62b57ee03928c12a3119dcaf78ffa1f4d6985f':
fate: Skip the checkasm test if CONFIG_STATIC is disabled
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '2835e9a9fd2b355e7936d1024ff1bf5fe454e428':
hevcdec: add P010 support for D3D11VA
This commit is a noop, see ccb94789e2
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '0ac2d86c4758e1419934905b6c092910296aa16a':
dxva2: Factorize DXVA context validity test into a single macro
This commit is (mostly) a noop, see 77742c75c5
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'f8a42d4f260db3eae4399fa8bd8c8c2c1d38f23a':
dxva2: Make ff_dxva2_get_surface() static and drop its name prefix
This commit is a noop, see fd0716b364
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '9026ec8aaf5fa19cb4fb266c16f608af0d863b2b':
matroskadec: make sure not to leave EbmlBin in an inconsistent state
This commit is a noop, see 5e1bacf2d4
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '9b1db2d33883c6ff3f8c7b2453146501ba14ca20':
vaapi_h264: Fix POC on IDR frames
This commit is a noop, see e72662e131
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'd08e02d929ff8be5f56bb1da0e439bf1ae557552':
vaapi_h265: Fix build failure with old libva without 10-bit surfaces
This commit is a noop, see b9514756ba
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '85ad5ea72ce3983947a3b07e4b35c66cb16dfaba':
aarch64: vp9mc: Fix a comment to refer to a register with the right name
This commit is a noop, see 0ba0187535
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '65074791e8f8397600aacc9801efdd17777eb6e3':
aarch64: vp9dsp: Fix vertical alignment in the init file
This commit is a noop, see 02cfb9a16e
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'c536e5e8698110c139b1c17938998a5547550aa3':
arm: vp9mc: Fix vertical alignment of operands
This commit is a noop, see 656d910981
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'd31f46e1999fab31be46f0cbce0546a5aa49fe48':
cmdutils: update copyright year to 2017
This commit is a noop, see d800d48fc6
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'ee164727dd64c199b87118917e674b17c25e0da3':
configure: Fix typo in incdir variable written to config.sh
This commit is a noop, see 6fdd35a312
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '5c83b4d550ea42653fece092987bab56ccc32ead':
fate: Unset the sig variable if ignoring a test failure
Merged-by: Clément Bœsch <cboesch@gopro.com>
Fixes the following warning:
libavutil/timecode.c:103:60: warning: '%02d' directive output may be truncated writing between 2 and 10 bytes into a region of size between 0 and 7
* commit '8a34f3659371680ca523aecfd9098c28f0f809eb':
build: Add version numbers to "Requires" entries in pkg-config files
This commit is a noop, see 6fdd35a312
Merged-by: James Almer <jamrial@gmail.com>
* commit '0982152c3fb05365597978c5d7cfeeb7ced01723':
matroskadec: fix SRT subtitle duration
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit '131644677970a3c4a0096270ea2a5b5d437c2e63':
http: Check for negative chunk sizes
This commit is a noop, see 2a05c8f813
Merged-by: James Almer <jamrial@gmail.com>
* commit '0b77a5933635293508e7289e7cf191ed166cf070':
Use correct printf conversion specifiers for POSIX integer types
See 549045254c
Merged-by: James Almer <jamrial@gmail.com>
* commit '92db5083077a8b0f8e1050507671b456fd155125':
build: Generate pkg-config files from Make and not from configure
build: Store library version numbers in .version files
Includes cherry-picked commits 8a34f36593 and
ee164727dd to fix issues.
Changes were also made to retain support for raise_major and build_suffix.
Reviewed-by: ubitux
Merged-by: James Almer <jamrial@gmail.com>
This is a newer API that is intended for decoders like the cuvid
wrapper. Until now, the wrapper required to set an awkward
"incomplete" hw_frames_ctx to set the device. Now the device
can be set directly, and the user can get AV_PIX_FMT_CUDA output
for a specific device simply by setting hw_device_ctx.
This still does a dummy ff_get_format() call at init time, and should
be fully backward compatible.
This avoids intermediates from overflowing (the final values are checked)
Fixes: runtime error: signed integer overflow: -167712 + -2147352576 cannot be represented in type 'int'
Fixes: 1298/clusterfuzz-testcase-minimized-5955580877340672
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This allows fuzzing decoders with the same codec_id
We also avoid register all to allow the linker to prune unused sections and symbols
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '11a9320de54759340531177c9f2b1e31e6112cc2':
build: Move build-system-related helper files to a separate subdirectory
"ffbuild" directory name is used instead of "avbuild".
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f9edc734e0ca3f6ef06c1ad0bd2c19c0c66f1ffa':
ratecontrol: Drop xvid-rc-related struct members unused after a6901b9c6
This commit is a noop, see 99b35a51cc
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5b26d3b789bd19a32dbe1e9c7ccab9498de7ee9b':
nvenc: Update check for lookahead
This commit is a noop, see 67db4ff3b6
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'a0c443a3980dc22eb02b067ac4cb9ffa2f9b04d2':
aarch64: vp9itxfm: Use the offset parameter to movrel
This commit is a noop, see 8b11a89c06
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'fc322d6a70189da24dbd445c710bb214eb031ce7':
tta: Convert to the new bitstream reader
mlp: Convert to the new bitstream reader
unary: Convert to the new bitstream reader
This merge is a noop, see
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html
Merged-by: Clément Bœsch <u@pkh.me>
* commit '45286a625c6ced1f5c4c842244cbb4509429abba':
h264dec: make sure to only end a field if it has been started
This commit is a noop. Our h264 slicing handling is different and does
not seem to be affected by the issue.
Merged-by: Clément Bœsch <u@pkh.me>
Because write_packet() fakely writes packets to muxer by queueing
them when muxer hasn't been initialized, it should also increment
frame_number fakely.
This is required because code in do_streamcopy() rely on
frame_number.
Should fix Ticket6227
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
This complex (-1 2 6 2 -1) filter slightly less reduces interlace 'twitter' but better retain detail and subjective sharpness impression compared to the linear (1 2 1) filter.
Signed-off-by: Thomas Mundt <tmundt75@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
the tested sample contain negative value in the red channel
need to be clip to zero, and not set to MAX_RED
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'c2fa6bb0e8703a7a6aa10e11f9ab36094416d83f':
mpeg12dec: move setting first_field to mpeg_field_start()
This commit is a noop, see 2f6f2f4f73
Merged-by: James Almer <jamrial@gmail.com>
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 a755b725ec.
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 'e807491fc6a336e4becc0cbc981274a8fde18aba':
mpeg12dec: avoid signed overflow in bitrate calculation
mpegvideo_parser: avoid signed overflow in bitrate calculation
This merge is a noop.
2017-04-29 12:54:15 @ubitux michaelni: is 740959fdbf enough to fix the overflow fixed in 58405de0951a843765625159402870c1eea3c3b1?
2017-04-29 12:55:53 @ubitux same question with e807491fc6
2017-04-29 13:21:45 michaelni ubitux, the libav code refered to is wrong for us and i doubt the problem it fixes applies to us.
2017-04-29 13:24:29 @ubitux michaelni: ok, for both commits?
2017-04-29 13:33:55 michaelni yes, they do more or less the same thing
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'cfa4eb4fba782f3f37a33be997b27a91a07053c9':
vaapi_decode: use the correct logging context
This commit is a noop, see 79307ae563
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'ea8b730d8e67152107d7fcdd5590bbb51ec236b1':
hevcdec: add a VAAPI hwaccel
This commit is a noop, see adb54e59c1
Merged-by: Clément Bœsch <u@pkh.me>
find_fps attempts to infer framerate from AVCodec's timebase. When this
results in a frame rate that isn't explicitly marked as supported in
av_timecode_check_frame_rate, find_fps returns the AVStream's
avg_frame_rate, which, per avformat.h, _may_ be set (or not).
mov_get_mpeg2_xdcam_codec_tag, mov_get_h264_codec_tag and
find_compressor attempt to call av_q2d on the return value of find_fps,
which in the above case, may result in division by zero and therefore,
an undefined frame rate when NaN is converted to int.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
compilers doing DCE at -O0 do not necessarily understand "complex" boolean expressions
Build succeeds with this change, this was the only failure
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Most code between the 2 functions was duplicated which made keeping
both in sync difficult.
This also fixes some discovered issues with encoding (incorrect
TF switching buffers) and reduces stack usage (reuse the already
allocated CeltFrame->scratch buffer for the quantized coefficients).
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This patch aims to reduce the number of input/output surfaces
NVENC allocates per session. Previous default sets allocated surfaces to 32
(unless there is user specified param or lookahead involved). Having large
number of surfaces consumes extra video memory (esp for higher resolution
encoding). The patch changes the surfaces calculation for default, B-frames,
lookahead scenario respectively.
The other change involves surface selection. Previously, if a session
allocates x surfaces, only x-1 surfaces are used (due to combination
of output delay and lock toggle logic). To prevent unused surfaces,
changing surface rotation to using predefined fifo.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
* commit 'd4a91e65343be5d79a4afa61c791191e1b57499a':
pthread_frame: do not run hwaccel decoding asynchronously unless it's safe
This commit is a noop, see e0cd598bc4
Merged-by: Clément Bœsch <u@pkh.me>
* commit '8dfba25ce89b62c80ba83e2116d549176c376144':
pthread_frame: ensure the threads don't run simultaneously with hwaccel
This commit is a noop, see 14bb15bfd5
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f7174d7ed045445d00a6d557236737d09ad32343':
configure: fix linking with MSVC when using --disable-optimizations
Merged-by: Clément Bœsch <u@pkh.me>
* commit '343e2833994655c252d5236a3394bf6db7a4d8b1':
pthread_frame: use better memory orders for frame progress
This commit is a noop, see c358c62550
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e94b9313b21c3d91a36ef064f7fe3e867616f47f':
fate: Add h264 test for frame num gaps
This commit is a noop, see b7e4ea0c80
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5c7f2cf81df06614f255f061850132355a01d75e':
h264_slice: Wait for refs to be available before we use them in error concealment
This commit is a noop, see 4413e950b2
Merged-by: Clément Bœsch <u@pkh.me>
* commit '86157e6db2c7a9222f77fa7e7f50fb9aebc3aa81':
hevc: decouple calling get_format() from exporting the SPS parameters
See 786032cad8 (which has been reverted
and replaced with Anton's version to reduce diffs between the two
projects).
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'fa1749dd34c55fb997c97dfc4da9383c9976ab91':
vp9: split superframes in the filtering stage before actual decoding
This commit is a noop.
2017-04-24 20:45:04 @ubitux BBB: btw, do you think you can get the bsf thing this week or we should skip it to give you more time and go on with the merges?
2017-04-24 20:45:20 @BBB I’m not sure I’ll finish it that soon
2017-04-24 20:45:26 @BBB I’d skip it and leave it for later
2017-04-24 20:45:35 @BBB I’ll do it, I promise, but I Can’t guarantee it’ll be done by $date
Merged-by: Clément Bœsch <u@pkh.me>
The header is not always available in the docker build environment
Suggested-by: Kostya Serebryany
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I tried doing this before, but it resulted in weird behaviour with
certain samples. I want to say I think I've got it sorted out now,
and the new autobsf stuff makes it trivial to turn on.
The native support for packed bframes is buggy and I think buggy
in ways beyond what I already try to account for, so this should be
a net improvements.
Previously, the pts value was initialised to AV_NOPTS_VALUE and so
it was not necessary to always set it. Now, with the new-new decode
API, this is no longer true. I'm not sure why I avoided setting the
pts when the decoder value was also AV_NOPTS_VALUE - it clearly
wouldn't have changed anything previously, but here we are.
Failing to do this, means the frame pts will be some random uninitalised
value.
The existing code will segfault if a closing tag shows up when there
was never an opening tag. This isn't a well formed style, but it's also
not a reason to crash.
Fixes: https://trac.ffmpeg.org/ticket/6303
The WebM DASH spec states:
The Initialization Segment shall not contain Clusters or Cues.
The Segment Index corresponds to the Cues.
Previously, it included the cues if they were at the front.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Output was apparently not tested for correctness. Passing overlapping
memory to snprintf causes undefined behavior, and usually resulted in
only the very last timestamp being written to metadata, and not a list
at all.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
There appears to be no need to treat interlaced videos differently,
also that code is flawed, as for at least one input cur_field would
be always 0.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
* commit '8fb4210ad8785c01fccf2fc59af6a6fa2892b6b2':
qsvdec_h2645: switch to the new generic filtering mechanism
Merged-by: James Almer <jamrial@gmail.com>
* commit '972c71e9cb63e24f57ee481e413199c7d88a8813':
lavc: add support for filtering packets before decoding
Merged-by: James Almer <jamrial@gmail.com>
Set BSF EOF flag only if pkt == NULL or both data and
side data are not present in packet.
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This reverts commit bfdca87ab5.
Packets with no data or side data will be valid EOF signal in an
upcoming merge.
Signed-off-by: James Almer <jamrial@gmail.com>
The new new decode API requires the decoder to ask for the next input
packet, and it cannot just return EAGAIN if that packet cannot be
processed yet. This means we must finally confront how we get this
decoder to block when the input buffer is full and no output frames
are ready yet.
In the end, that isn't too hard to achieve - the main trick seems to
be that you have to aggressively poll the hardware - it doesn't seem
to make any forward progress if you sleep.
Signed-off-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>
Purpose: libavutil/thread.h: Fixed g++ build error when ASSERT_LEVEL
is greater than 1. This is only relevant when thread.h is included by
C++ files. In this case, the relevant code is only defined if
HAVE_PTHREADS is defined as 1. Use configure --assert-level=2 to do
so.
Note: Issue discovered as a result of Coverity build failure. Cause
of build failure pinpointed by Hendrik Leppkes.
Comments:
-- libavutil/thread.h: Altered ASSERT_PTHREAD_NORET definition such
that it uses av_make_error_string instead of av_err2str().
av_err2str() uses a "parenthesized type followed by an initializer
list", which is apparently not valid C++. This issue started
occurring because thread.h is now included by the DeckLink C++
files. The alteration does the equivalent of what av_err2str()
does, but instead declares the character buffer as a local
variable.
Signed-off-by: Marton Balint <cus@passwd.hu>
This should help coverity realize that src[] is inited
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It should not be a value larger than the number of streams we have,
or it will cause invalid reads and/or SIGSEGV.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This seems to be non-optional, and if the muxer is run without it,
strlen() is run on NULL, causing a segfault.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ASC frames smaller than AAC_ADTS_HEADER_SIZE were being discarded.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Add an option to webm_dash_manifest demuxer to specify a value for
"bandwidth" field in the DASH manifest. The value is then used by
the muxer. Fixes an existing FIXME in the code.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: James Zern <jzern@google.com>
* commit '6aa4ba7131b6e8668e33430e18101a051fe492eb':
dxva2: Keep code shared between dxva2 and d3d11va under the correct #if
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f1248fae90b45501af4e8743d373e79191470331':
configure: Handle dxva2 optional components in the standard way
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'a6901b9c6bd51396c1159f1a07f9f5042328cda6':
Drop libxvid rate control support for mpegvideo encoding
This commit is a noop, there is no known issue with it.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '7d81698b89172d2dcf1b78d4b42ba86262360559':
vaapi_h265: Fix CFR mode with framerate set in AVCodecContext
This commit is a noop, see 37de9ce713
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'ade370a4d7eab1866b6023c91c135d27c77ca465':
lavfi: Add VAAPI deinterlacer
This commit is a noop, see 359586f14f
Merged-by: Clément Bœsch <u@pkh.me>
* commit '39fbcf8f76ff2e7cd8d09307e6aacc70ce8f5fed':
configure: Fix _libs vs. _extralibs oversight
This commit is a noop, see 9bf3d84089
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'a7101eb40e69ada3872ec5aebe9c5c165745fb3a':
configure: Simplify some library checks via check_lib()
This commit is a noop as it doesn't apply to FFmpeg:
- the nanosleep check doesn't use add_extralibs in FFmpeg
- the pthread checks check multiple functions before add the extra
libraries
Merged-by: Clément Bœsch <u@pkh.me>
* commit '1818a640cfdccd52e97edf13564f45bc3d0d93eb':
build: Fix dependencies for alsa/jack/sndio support
Added explicit enable (which will be automatically added later on in
ee480790c) to actually fix this commit. Without the explicit enables,
alsa, jack and sndio gets disabled.
Also added jack, alsa and sndio to the have list so the HAVE_* are
populated to make (this fixes the SKIPHEADERS chunks).
Merged-by: Clément Bœsch <u@pkh.me>
Purpose: avdevice/decklink: Removed pthread dependency by replacing
semaphore used in code appropriately. Doing so makes it easier to
build ffmpeg using Visual C++ on Windows. This is a contination of
Kyle Schwarz's "avdevice/decklink: Remove pthread dependency" patch
that is available at https://patchwork.ffmpeg.org/patch/2654/ . This
patch wasn't accepted, and as far as I can tell, there was no
follow-up after it was rejected.
Notes: Used Visual Studio 2015 (with update 3) for this.
Comments:
-- configure: Eliminated pthreads dependency for decklink_indev_deps
and decklink_outdev_deps and replaced with threads dependency
-- libavdevice/decklink_common.cpp / .h:
a) Eliminated semaphore and replaced with a combination of a mutex,
condition variable, and a counter (frames_buffer_available_spots).
b) Removed include of pthread.h and semaphore.h and now using
libavutil/thread.h instead.
-- libavdevice/decklink_dec.cpp: Eliminated include of pthread.h and
semaphore.h.
-- libavdevice/decklink_enc.cpp:
a) Eliminated include of pthread.h and semaphore.h.
b) Replaced use of semaphore with the equivalent using a combination
of a mutex, condition variable, and a counter
(frames_buffer_available_spots). In theory, libavutil/thread.h and
the associated code could have been modified instead to add
cross-platform implementations of the sem_ functions, but an
inspection of the ffmpeg source base indicates that there are only
two cases in which semaphores are used (including this one that was
replaced), so it was deemed to not be worth the effort.
Signed-off-by: Marton Balint <cus@passwd.hu>
* commit '92e6b31c3b31be5d6fcad6bf0030bea86a1c8360':
dxva2: Adjust multiple inclusion guard names to follow convention
This commit is a noop, see 180f9a0958
Merged-by: James Almer <jamrial@gmail.com>
* commit 'dbfe60caca2e8323efa7aba6762dce7be2eba390':
vf_hwupload_cuda: Add min/max limits for device option
This commit is a noop, see4df5a6a26a8aa08bbc6d027c2fb44fcf870e98d7
Merged-by: James Almer <jamrial@gmail.com>
* commit '4efea4ce75fbea3e5f8be8040068bfaaffbb2718':
APIChanges: Mention where release 12 was cut
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'fc85646ad495f3418042468da415af73a7a07334':
libopusdec: fix out-of-bounds read
libschroedingerdec: fix leaking of framewithpts
libschroedingerdec: don't produce empty frames
This commit is a noop, see
a86ebbf7f63c0328d58d8c8f543b81
Merged-by: James Almer <jamrial@gmail.com>
Made appropriate changes to be able to successfully
build C++ files using a Visual C++ build on Windows.
Based on an earlier patch by Kyle Schwarz.
Comments:
-- compat/w32pthreads.h: Made appropriate changes to w32pthreads.h to
get it to build when it is being included in a C++ file and built
with Visual C++. This is mostly a copy of Kyle Schwarz's patch as
described above.
-- configure:
a) Now calling set_ccvars CXX to cause the various CXX_ variables to
be setup properly. For example, with MSVC (Microsoft Visual C++),
this causes CXX_O to be set to -Fo$@ instead of using the default
value. The default value does not work with Visual C++. This
change will also have the impact of correcting CXX_O (and possibly
CXX_C) for other compilers, although this is really only relevant
for the Intel compiler, in addition to MSVC.
b) Now using cl for the C++ compiler for the MSVC toolchain. This is
currently only relevant for building the
Blackmagic/Decklink-related files under avdevice.
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'd3da8a0035734529c4e26696c9a0c6cb56633838':
omx: Fix allocation check
This commit is a noop, see 16a75304fe
Merged-by: James Almer <jamrial@gmail.com>
* commit 'd32bdadda86b35c2960e4de877cf081b9d2dadb3':
qsvdec: Fix memory leak on error
This commit is a noop, see b6f80b16d1
Merged-by: James Almer <jamrial@gmail.com>
* commit '2170017a1cd033b6f28e16476921022712a522d8':
avutil: fix data race in av_get_cpu_flags()
This commit is a noop, see fed50c4304
Merged-by: James Almer <jamrial@gmail.com>
* commit '892acc70105df9e6f7773bdde85b3e9541098525':
configure: Fail if cuda was enabled and is not available
This commit is a noop. Our CUDA implementation is autodectected.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'fbec58daa2351cbe9fc758d8735c23ff03313db4':
build: Add an internal component for hevc_ps code
This commit is a noop, see 498e9e8e2a
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f912fd767e55bbb5a1554bd99bacab007659609c':
Add missing #includes for standalone spherical-information-related headers
fate: Add spherical and stereo3d mov tests
avprobe: Allow specifying multiple stream entries to be shown
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'e90137c045721a1635cc241eb1e1be1126389c38':
mov: Export spherical information
lavc: Add spherical packet side data API
lavu: Add AVSphericalMapping type and frame side data
This commit is a noop, see
8f58ecc344e7a6f8c9724dcdecf471
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c833c2034f4ee77fe2ee3470f3f5f84415673b3b':
build: Ensure that the "all" target appears before all Makefile includes
Merged-by: James Almer <jamrial@gmail.com>
* commit '6bd9590b33742f1cceecc0c0d81b3caf3d8a4e1a':
build: Have old H.264/HEVC nvenc encoders select their new counterparts
Merged-by: James Almer <jamrial@gmail.com>
* commit '3e105d08848162b90d886bde59c010d4b0362a4b':
build: Move entries related to building TOOLS to a subdirectory Makefile
Merged-by: James Almer <jamrial@gmail.com>
* commit '4104cc56225f29ce1cded8b2876f8748460232a6':
build: Warn that reconfiguration is necessary if version.h files changed
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f22da2cdf90dc892d483e2d4003cffc0500816f6':
configure: add -fPIE instead of -pie to C flags for ThreadSanitizer
This commit is a noop, see 3f55752cd5
Merged-by: James Almer <jamrial@gmail.com>
* commit '404cb74793284aa03e2e1a7e911c980c4cba0e9e':
configure: Pass CFLAGS_HEADERS through the right CFLAGS filter
Merged-by: James Almer <jamrial@gmail.com>
* commit '9265364bec0af2e8b7c3a6de7bfc8291a0b70bca':
build: Separate avisynth and avxsynth support
Mostly noop, since it could break linux configure with --enable-avisynth,
and the configure code which was simplified isn't even present in
ffmpeg.
Only merged the cosmetic re-ordering in the Makefile.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
The custom callback can cause significant CPU usage on Windows for some large
files with many index entries for some reason.
v2: Move check after parsing options.
Signed-off-by: Marton Balint <cus@passwd.hu>
Use AVBprint to implement av_strreplace
add av_strreplace test case TEST_STRREPLACE
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
This avoids potential undefined behavior in debug mode while still allowing
developers which want to check for potential additional overflows to do so
by manually enabling this.
Reviewed-by: wm4
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Experimental VP9 support was added to the muxer recently.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This changes nothing but is nicer looking as this checks rlen
Maybe this helps coverity remove CID1397743
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '601f8dde13ccd0e1993b7840a0304fa2cfe53432':
configure: Move COMPONENT_LIST to the bottom of CONFIG_LIST
Merged-by: James Almer <jamrial@gmail.com>
* commit '5d45fe7da972da528915fbdfe3dbf22eb2effd01':
build: Add EXTRALIBS to TOOLS linker command
This commit is a noop. We're already adding EXTRALIBS to the linker
command on a case by case basis.
Merged-by: James Almer <jamrial@gmail.com>
Use ff_hevc_decode_extradata() instead, which correctly only tries
to decode parameter set NAL units and not any other NAL that may be
present in extradata.
Reviewed-by: nevcairiel
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes valgrind warnings about "Use of uninitialised value of size 8"
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '2a096440768b1086bb437939f827b8b7a5716bf7':
configure: Separate package name and version requirements in helper functions
Merged-by: James Almer <jamrial@gmail.com>
* commit '6c916192f3d7441f5896f6c0fe151874fcd91fe4':
mimic: Convert to the new bitstream reader
metasound: Convert to the new bitstream reader
lagarith: Convert to the new bitstream reader
indeo: Convert to the new bitstream reader
imc: Convert to the new bitstream reader
webp: Convert to the new bitstream reader
This merge is a noop, see
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html
Merged-by: Clément Bœsch <u@pkh.me>
* commit '14bba44fb23c63bf82b2c15f5c754b2fed7dbea9':
build: Drop support for configuring library name suffixes
This commit is a noop. The feature is useful. Until recently I was one
of these no known users.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '1ea77aae927c7310034b1f75d4f1c2676fe641f2':
configure: Drop bogus xcb_event variables
This commit is a noop, see 50138ea4f7
Merged-by: Clément Bœsch <u@pkh.me>
As it gives excellent encoding gains at an insignificant speed increase
and passes fate without problems, it should now be safe to enable by
default.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
When coding lossless jpeg the priv context will be pointing to LJpegEncContext
rather than MpegEncContext, which the function expects.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
* commit '33a2b73b98374de4781ae0497cf74b2ce07a9615':
mpeg4audio: correctly propagate meaningful error values
This commit is a noop, see 50b1453915
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'a91f1023bc06091ef84dce0f1e12b72d7f3ba3ca':
examples: fix a typo in an error message
This commit is a noop, see 3aa1ff30f3
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'cad42fadcd2c2ae1b3676bb398844a1f521a2d7b':
aarch64: vp9itxfm: Skip empty slices in the first pass of idct_idct 16x16 and 32x32
This commit is a noop, see 8b11a89c06
Merged-by: Clément Bœsch <u@pkh.me>
* commit '9c8bc74c2b40537b0997f646c87c008042d788c2':
arm: vp9itxfm: Skip empty slices in the first pass of idct_idct 16x16 and 32x32
This commit is a noop, see 388f6e6715
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3c87039a404c5659ae9bf7454a04e186532eb40b':
arm: vp9itxfm: Only reload the idct coeffs for the iadst_idct combination
This commit is a noop, see ecd343aa1f
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'c4c5f5386c83bb8d66f8d67cd8533c8697f06d04':
vp9dsp: add DC only versions for idct/idct.
This commit is a noop, see 64821f5a7c
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e4382a4ab48138d43a19ea0da96f536a5e49b50c':
hevc: Eliminate pointless variable indirection
This commit is a noop, the code is different in FFmpeg.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '0983f9117f31521643162cb85380672495a9de1b':
metasound: Drop unused tables
This commit is mostly a noop, see
276a8666d2e8319f602e
Merged-by: Clément Bœsch <u@pkh.me>
* commit '8b56dbe7435d8cfe3964f447fc45fe98db5d9042':
configure: Do not add newlines in filter()/filter_out() functions
Merged-by: Clément Bœsch <u@pkh.me>
or if x/y go beyond padded area.
This is mostly useful when paired with the aspect option.
Defaults aren't changed.
Idea for this was taken from mpv's soon-to-be-removed expand vf.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
While they shouldn't be present, they are harmless if they are.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This merges commits 8e2ea69135 and
096a8effa3 by Anton Khirnov, with the
following change:
- extract_extradata_check() is added to know if the codec is supported
by the bsf before trying to initialize it. This behaviour is similar to
the old AVCodecParser.split checks.
The FATE reference changes are due to the filtered out NAL units that
the old AVCodecParser.split implementation left alone.
Decoding is unchanged as the functions that parse extradata simply
ignored said unnecessary NAL units.
Signed-off-by: James Almer <jamrial@gmail.com>
The av_log() is done outside the lock, but this way the accesses to the
field (reads and writes) are always protected by a mutex. The av_log()
is not run inside the lock context because it may involve user callbacks
and doing that in performance-sensitive code is probably not a good idea.
This should fix occasional tsan warnings when running fate-h264, like:
WARNING: ThreadSanitizer: data race (pid=10916)
Write of size 4 at 0x7d64000174fc by main thread (mutexes: write M2313):
#0 update_context_from_user src/libavcodec/pthread_frame.c:335 (ffmpeg+0x000000df7b06)
[..]
Previous read of size 4 at 0x7d64000174fc by thread T1 (mutexes: write M2311):
#0 ff_thread_await_progress src/libavcodec/pthread_frame.c:592 (ffmpeg+0x000000df8b3e)
I'm hoping that this will address the remaining tsan fate-h264 issues:
WARNING: ThreadSanitizer: data race (pid=24478)
Read of size 8 at 0x7dbc0001c828 by main thread (mutexes: write M3243):
#0 ff_h264_ref_picture src/libavcodec/h264_picture.c:107 (ffmpeg+0x0000013b78d8)
[..]
Previous write of size 1 at 0x7dbc0001c82e by thread T2 (mutexes: write M3245):
#0 ff_h264_direct_ref_list_init src/libavcodec/h264_direct.c:137 (ffmpeg+0x000001382c93)
But I'm not sure because I haven't been able to reproduce locally.
* commit '239d02eff3ffe9f7d40caa21dde50fb4a0e94c24':
avisynth: Cast to the right type when loading avisynth library functions
This commit is a noop, we are using dlsym() instead of GetProcAdress().
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3fe2a01df7f2c193805809f57b61d79607572351':
lavc: move decoding-related code from utils.c to a new file
Merged-by: James Almer <jamrial@gmail.com>
* commit '328cd2b599bc2d0d38f3c12606fa2a66eeec016e':
lavc: move encoding-related code from utils.c to a new file
Merged-by: James Almer <jamrial@gmail.com>
* commit '45d199d5b0b7f09eb9baa29929a3bd07ed46223b':
aac_adtstoasc_bsf: validate and forward extradata if the stream is already ASC
This commit is a noop, see 6e1902bab4
Merged-by: James Almer <jamrial@gmail.com>
* commit '1762a39e09a3edc27d1ef7bc50070f496b893aa4':
mss2: only use error correction for matching block counts
This commit is a noop, see 2566ad98b0
Merged-by: James Almer <jamrial@gmail.com>
* commit 'd0c84c41d33ffd270d5f9fe0290e08341397fdee':
avconv: Fix the audio next dts computation
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'eb135516e6f61481877163bfc55a3161d4544092':
ac3enc: Avoid unnecessary macro indirections
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'e22c63ac74b2968075be8bf0d2deb1ee63b28976':
ac3enc: Reshuffle some float/fixed-mode ifdefs to avoid a dummy function
Merged-by: James Almer <jamrial@gmail.com>
* commit 'd30719e62de68975cbc7ffd318df03a183037563':
hwcontext_vaapi: Don't abort on failing to allocate from a fixed-size pool
This commit is a noop, see 2b8151c806
Merged-by: James Almer <jamrial@gmail.com>
* commit 'dc4b62502876c0ebeeba317233cd1348c5b0b2b7':
tta: use get_unary() instead of a custom implementation
This commit is a noop, see 58b36959dd
Merged-by: James Almer <jamrial@gmail.com>
* commit 'e122b12c88487ac8766ff4eb071856b0666f0134':
build: Drop gcrypt support
This commit is a noop. GCrypt support is exposed in configure as a
command line option, and it's independent of GnuTLS.
Merged-by: James Almer <jamrial@gmail.com>
It is assigned from 64bit input in some branches and used with 64bit timestamps
This thus fixes a potential integer truncation
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Consider the following sequence of events:
- open a codec without AV_CODEC_CAP_DELAY
- decode call fails with an error
- ff_thread_flush() is called
- drain packet is sent
Then the last step would make ff_thread_decode_frame() return an error,
because p->result can still be set to an error value. This is because
submit_packet returns immediately if AV_CODEC_CAP_DELAY is not set, and
no worker thread gets the chance to reset p->result, yet its value is
trusted by ff_thread_decode_frame().
Fix this by clearing the error fields on flush.
Fixes tsan warnings like this in fate-vp8-test-vector-007:
WARNING: ThreadSanitizer: data race (pid=65909)
Write of size 4 at 0x7d8c0000e088 by thread T1:
#0 vp8_decode_mb_row_sliced vp8.c:2519 (ffmpeg:x86_64+0x100995ede)
[..]
Previous write of size 4 at 0x7d8c0000e088 by thread T2:
#0 vp8_decode_mb_row_sliced vp8.c:2519 (ffmpeg:x86_64+0x100995ede)
Fixes tsan warnings like this in fate-vp8-test-vector-007:
WARNING: ThreadSanitizer: data race (pid=3590)
Write of size 4 at 0x7d8c0000e07c by thread T2:
#0 decode_mb_row_no_filter src/libavcodec/vp8.c:2330 (ffmpeg+0x000000ffb59e)
[..]
Previous write of size 4 at 0x7d8c0000e07c by thread T1:
#0 decode_mb_row_no_filter src/libavcodec/vp8.c:2330 (ffmpeg+0x000000ffb59e)
This removes the last use of the ff_put/add_pixels_clamped global
function pointers, and as such they are removed.
This patch has a negative effect on performance on MIPS, since there's
a SIMD-optimized put/add_pixels_clamped, but no xvid or jrev. From a
code maintenance point of view, that is probably acceptable.
Because the global function pointers are removed, this fixes the following
tsan warnings when running e.g. fate-dnxhr-parse:
WARNING: ThreadSanitizer: data race (pid=29917)
Write of size 8 at 0x0000025b12d8 by thread T2 (mutexes: write M1543):
#0 ff_idctdsp_init src/libavcodec/idctdsp.c:313 (ffmpeg+0x00000044b68e)
[..]
Previous write of size 8 at 0x0000025b12d8 by thread T1 (mutexes: write M1541):
#0 ff_idctdsp_init src/libavcodec/idctdsp.c:313 (ffmpeg+0x00000044b68e)
These use the mmx IDCT, but sse2 put/add_pixels_clamped implementations.
This way we don't need to use the ff_put/add_pixels_clamped function
pointers.
Instead, hardcode the use of the _arm implementation of add_pixels,
and use the C version for put_pixels (as no arm-optimized version
exists). Since there's separate implementations of idct{,_put,_add}
for neon, this has no practical impact on performance.
This tries to handle cases where separate invocations of decode_frame()
(each running in separate threads) write to respective fields in the
same AVFrame->data[]. Having per-field owners makes interaction between
readers (the referencing thread) and writers (the decoding thread)
slightly more optimal if both accesses are field-based, since they will
use the respective producer's thread objects (mutex/cond) instead of
sharing the thread objects of the first field's producer.
In practice, this fixes the following tsan-warning in fate-h264:
WARNING: ThreadSanitizer: data race (pid=21615)
Read of size 4 at 0x7d640000d9fc by thread T2 (mutexes: write M1006):
#0 ff_thread_report_progress pthread_frame.c:569 (ffmpeg:x86_64+0x100f7cf54)
[..]
Previous write of size 4 at 0x7d640000d9fc by main thread (mutexes: write M1004):
#0 update_context_from_user pthread_frame.c:335 (ffmpeg:x86_64+0x100f81abb)
This fixes a proble where ffmpeg would cause crash to do a seek when the network disconnect.
The log like this:
01-01 10:53:03.441 6580 6580 F DEBUG : backtrace:
01-01 10:53:03.441 6580 6580 F DEBUG : #00 pc 0002942e /system/lib/libavformat.so (ffurl_write+9)
Signed-off-by: tiejun.peng <tiejun.peng@foxmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes the following tsan warning when running fate-vsynth_lena-ffvhuff:
WARNING: ThreadSanitizer: data race (pid=6484)
Write of size 8 at 0x7d64000154b8 by main thread (mutexes: write M1331):
#0 update_context_from_user src/libavcodec/pthread_frame.c:331 (ffmpeg+0x000000dca887)
[..]
Previous read of size 8 at 0x7d64000154b8 by thread T2 (mutexes: write M1334):
#0 draw_slice src/libavcodec/huffyuvdec.c:857 (ffmpeg+0x000000bcc86f)
This adds partial support for the RFC 4175 (raw video over RTP). The
only supported formats are the YCbCr-4:2:2 8 bit because it's natively
supported by FFmpeg with pixel format UYVY, and 10 bit which requires
the vrawdepay codec to convert the payload in a format handled by
FFmpeg.
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
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>
* commit 'bf2f748fc74fff5272075e1fe1c07b4152421526':
configure: Use correct libm linker flag during math function checks
Merged-by: James Almer <jamrial@gmail.com>
* commit 'ce6f780bc6656ad3895f81a988b239ad3c8af4b8':
configure: Add missing asyncts filter, movie filter, and output example deps
Merged-by: James Almer <jamrial@gmail.com>
* commit '6a1ea4ec932f4fc9fdc00ec51ee070b298ddb35f':
arm: warn/error on movrelx usage problematic with PIC on ELF
Merged-by: James Almer <jamrial@gmail.com>
* commit '233d50b275dd7cf6cc0656851e670e1b2dfba56f':
qt-faststart: Do not try to use fancy 64-bit seeking functions on mingw32ce
Merged-by: James Almer <jamrial@gmail.com>
* commit '537b5b773b317af79d3a5b576ee9683e15ed84f6':
rtmpdh: Do global initialization before running the test
Merged-by: James Almer <jamrial@gmail.com>
* commit '2f99117f6ff24ce5be2abb9e014cb8b86c2aa0e0':
aarch64: vp9itxfm: Don't repeatedly set x9 when nothing overwrites it
This commit is a noop, see 37cb224e3e
Merged-by: James Almer <jamrial@gmail.com>
* commit '2dbe2aa2c2d4f02d2669feae45dee4fc45414813':
rdt: Convert to the new bitstream reader
ogg: Convert to the new bitstream reader
mpegts: Convert to the new bitstream reader
xsubdec: Convert to the new bitstream reader
xan: Convert to the new bitstream reader
wnv1: Convert to the new bitstream reader
vima: Convert to the new bitstream reader
vble: Convert to the new bitstream reader
utvideodec: Convert to the new bitstream reader
twinvq: Convert to the new bitstream reader
tscc2: Convert to the new bitstream reader
truespeech: Convert to the new bitstream reader
tiertex: Convert to the new bitstream reader
truemotion2: Convert to the new bitstream reader
svq1dec: Convert to the new bitstream reader
smacker: Convert to the new bitstream reader
sipr: Convert to the new bitstream reader
rtjpeg: Convert to the new bitstream reader
ra288: Convert to the new bitstream reader
ra144: Convert to the new bitstream reader
This merge is a noop, see
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html
Merged-by: James Almer <jamrial@gmail.com>
* commit '79566ec8c77969d5f9be533de04b1349834cca62':
arm: vp9itxfm: Rename a macro parameter to fit better
This commit is a noop, see f69dd26df5
Merged-by: James Almer <jamrial@gmail.com>
* commit '721bc37522c5c1d6a8c3cea5e9c3fcde8d256c05':
arm/aarch64: vp9itxfm: Fix indentation of macro arguments
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit '06fec74cacbb0ef7f3e5ea0e6c9ced1b6fd7565d':
checkasm: vp9dsp: benchmark all sub-IDCTs (but not WHT or ADST).
This commit is a noop, see 1c8fbd7b90
Merged-by: James Almer <jamrial@gmail.com>
* commit 'effc1430b2fe5997d9d55bf28dc507c27125eb27':
Revert "checkasm: vp9dsp: Benchmark the dc-only version of idct_idct separately"
Merged-by: James Almer <jamrial@gmail.com>
* commit '12ab667e219e7fbf8e9aef3731039b75c822df25':
matroska: use av_stream_add_side_data() for stereo3d side data
mov: Use av_stream_add_side_data() for displaymatrix side data
utils: Add av_stream_add_side_data()
This is a noop, see
2ab50647ff77f033eb982343f23e4d
Merged-by: James Almer <jamrial@gmail.com>
* commit '286ab878bd39b56008035638227b3ecb8ec5bbb7':
fate.sh: Allow setting other make flags for running tests
Merged-by: James Almer <jamrial@gmail.com>
* commit 'aa498c3183236a93206b4a0e8225b9db0660b50d':
avpacket: fix leak on realloc in av_packet_add_side_data()
This commit is a noop, see 574929d8b6
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f78d360bba6dcfb585847a49a84e89c25950fbdb':
examples/decode_video: use a parser for splitting the input
Merged-by: James Almer <jamrial@gmail.com>
* commit '5f102a9559099429826e84758b8b5182244c52db':
examples/encode_video: switch to the new encoding API
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '45a1ce2ff7688656aacd53c27de5815a7ec13afe':
examples/decode_audio: handle planar audio now produced by the MP2 decoder
This commit is a noop, we use a simpler and more generic method to write
the samples.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '3d66717f7cb5555257244be8f5bce172ed3af7ac':
examples/decode_audio: use the new audio decoding API
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '0946c754d99c05413e813ee515039adcf0f9232a':
examples/decode_audio: use a parser for splitting the input
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'f92d7bdfddfaac04b3bb31f2749d173ca1d8ba6d':
libopusdec: default to stereo for invalid number of channels
This commit is a noop, see 8c8f543b81
Merged-by: Clément Bœsch <u@pkh.me>
* commit '6427379f23eb4d2b82d8d274c616f68b65a2f723':
als: Restructure DEBUG ifdefs to avoid unused function parameter warnings
ac3enc: Restructure DEBUG ifdefs to avoid unused function parameter warnings
ape: Restructure DEBUG ifdefs to avoid unused function parameter warnings
These 3 commits are not merged.
These commits were actually controversial in Libav. A good rationale can
be found here:
https://lists.libav.org/pipermail/libav-devel/2016-November/080698.htm
Merged-by: Clément Bœsch <u@pkh.me>
Fixes tsan warnings in fate-apng:
WARNING: ThreadSanitizer: data race (pid=51230)
Read of size 4 at 0x7d50000042fc by main thread (mutexes: write M1000):
#0 frame_copy_props frame.c:302 (ffmpeg:x86_64+0x1019a35d6)
[..]
Previous write of size 4 at 0x7d50000042fc by thread T1 (mutexes: write M997):
#0 decode_idat_chunk pngdec.c:708 (ffmpeg:x86_64+0x100f5562a)
* commit '97cd7a3dc005a0ad1656dbb2af92e9c5d0731f21':
rtpdec_mpeg4: const correctness for parse_fmtp_config()
This commit is a noop, see ed491db3e5
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'a1d9de304fe63614e3aa8117fef17491fa80093d':
Fix some mismatches between function parameter and doxygen parameter names.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '4d960a11855f4212eb3a4e470ce890db7f01df29':
aarch64: vp9itxfm: Use w3 instead of x3 for the int eob parameter
This commit is a noop, see a95e7de41d
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e5b0fc170f85b00f7dd0ac514918fb5c95253d39':
arm: vp9itxfm: Simplify the stack alignment code
This commit is a noop, see a71cd8439f
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3c7fa8cbb93dba96acb12aef6e00d929c1da1ae8':
hlsenc: Fix the openssl support
This commit is a noop, see edc43c571d
Merged-by: Clément Bœsch <u@pkh.me>
* commit '0b5a26e8bcd219efe5da3a6d39b588fabf91f2b9': (35 commits)
qdm2: Convert to the new bitstream reader
qcelp: Convert to the new bitstream reader
pcx: Convert to the new bitstream reader
opus: Convert to the new bitstream reader
nellymoser: Convert to the new bitstream reader
jvdec: Convert to the new bitstream reader
hqx: Convert to the new bitstream header
hq_hqa: Convert to the new bitstream reader
gsm: Convert to the new bitstream reader
g72x: Convert to the new bitstream reader
g2meet: Convert to the new bitstream reader
fraps: Convert to the new bitstream reader
flashsv: Convert to the new bitstream reader
faxcompr: Convert to the new bitstream reader
exr: Convert to the new bitstream reader
escape130: Convert to the new bitstream reader
escape124: Convert to the new bitstream reader
dvdsubdec: Convert to the new bitstream reader
dss_sp: Convert to the new bitstream reader
cook: Convert to the new bitstream reader
...
This merge is a noop, see
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209609.html
Merged-by: Clément Bœsch <u@pkh.me>
Fixes a reported (but false) race condition in tsan for fate-apng:
WARNING: ThreadSanitizer: data race (pid=6274)
Read of size 4 at 0x7d680001ec78 by main thread (mutexes: write M1338):
#0 update_thread_context src/libavcodec/pngdec.c:1456 (ffmpeg+0x000000dacf0c)
[..]
Previous write of size 4 at 0x7d680001ec78 by thread T1 (mutexes: write M1335):
#0 decode_idat_chunk src/libavcodec/pngdec.c:737 (ffmpeg+0x000000dae951)
Values from subsequent values are guaranteed to be identical (since
poc and nal_unit_type are checked to be the same between slices), so
this doesn't affect output in any way, but does resolve the remaining
reported race conditions (by tsan) in fate-hevc.
In practice, this fixes tsan warnings like this:
WARNING: ThreadSanitizer: data race (pid=25334)
Read of size 4 at 0x7d9c0001adcc by main thread (mutexes: write M1386):
#0 hevc_update_thread_context src/libavcodec/hevcdec.c:3310 (ffmpeg+0x000000b41c7c)
[..]
Previous write of size 4 at 0x7d9c0001adcc by thread T1 (mutexes: write M1383):
#0 hls_slice_header src/libavcodec/hevcdec.c:596 (ffmpeg+0x000000b43a22)
Otherwise the thread may still be in the middle of decoding a previous
frame, which would effectively trigger a race condition on any field
concurrently read and written.
In practice, this fixes tsan warnings like the following:
WARNING: ThreadSanitizer: data race (pid=17380)
Write of size 4 at 0x7d64000160fc by main thread:
#0 update_context_from_user src/libavcodec/pthread_frame.c:335 (ffmpeg+0x000000dca515)
[..]
Previous read of size 4 at 0x7d64000160fc by thread T2 (mutexes: write M1821):
#0 ff_thread_report_progress src/libavcodec/pthread_frame.c:565 (ffmpeg+0x000000dcb08a)
Should fix tsan warnings in fate-fifo-muxer-h264/wav:
WARNING: ThreadSanitizer: data race (pid=26552)
Write of size 4 at 0x000001e0d7c0 by main thread:
#0 transcode_init src/ffmpeg.c:3761 (ffmpeg+0x00000050ca1c)
[..]
Previous read of size 4 at 0x000001e0d7c0 by thread T1:
#0 decode_interrupt_cb src/ffmpeg.c:460 (ffmpeg+0x0000004fde19)
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)
This is how the ref list manager links bitstream IDs to H264Picture/Ref
objects, and is local to the producer thread. There is no need for the
consumer thread to know the bitstream IDs of its references in their
respective producer threads.
In practice, this fixes tsan warnings when running fate-h264:
WARNING: ThreadSanitizer: data race (pid=19295)
Read of size 4 at 0x7dbc0000e614 by main thread (mutexes: write M1914):
#0 ff_h264_ref_picture src/libavcodec/h264_picture.c:112 (ffmpeg+0x0000013b3709)
[..]
Previous write of size 4 at 0x7dbc0000e614 by thread T2 (mutexes: write M1917):
#0 build_def_list src/libavcodec/h264_refs.c:91 (ffmpeg+0x0000013b46cf)
* commit 'e18ba2dfd2d19aedc8afccf011d5fd0833352423':
hwcontext_dxva2: make sure the sw frame format is the right one during transfer
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '9d7026574bbbe67d004a1c32911da75375692967':
hwcontext_dxva2: fix handling of the mapping flags
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '0d3176e32f351d18d6174d8b05796829a75a4c6b':
hwcontext_dxva2: do not assume the destination format during mapping is always the right one
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '0a4b9d0ccd10b3c39105f99bd320f696f69a75a2':
hlsenc: Add encryption support
This commit is a noop, see 907ac20aa2
Note that this commit differs from our encryption support in various
ways so it may need some adjustments in the future.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'bb265b764a055f2dc576b9aec62460d9580868f4':
examples/transcode_aac: Drop pointless return value const qualifier
This commit is a noop, the function doesn't exist in FFmpeg anymore
since e181e2909b.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'bfe92dfe60f601b3f20a918ffcc0acdf40a5955c':
Ignore all generated example binaries
This commit is a noop, the .gitignore was updated during the merges of
these examples.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3cc3463f306f425f76bd962755df1132eeac6dfa':
avisynth: Support pix_fmts added to AviSynth+
This commit is mostly a noop, see
92916e8542.
Cosmetics and a small fix are merged.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'aaae59700f7fc10fd80cb93b38c5d109900872d9':
avisynth: Simplify the pix_fmt check for the newer AviSynth API
This commit is a noop, see 0ed5c3ce81
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'bcefafa226dcda23d4d9af9601d19389cb918a5b':
avisynth: Fix setting stream timebase
This commit is a noop, see 8009a1f1fd
Merged-by: Clément Bœsch <u@pkh.me>
* commit '481ff3cf018811ba3235f1c236e970f32a6300b9':
fate: Add h264 and hevc extradata reload tests
Only the HEVC part is merged, see 00c8079816
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'd5d62ce6d643de704e7bd62a2375e6391c0ffb9a':
mov: Fix identity matrix boolean logic
This commit is a noop, see 7010ebdf1f
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e7ae8f7a715843a5089d18e033afb3ee19ab3057':
aarch64: vp9: loop filter: replace 'orr; cbn?z' with 'adds; b.{eq,ne};
This commit is a noop, see e7ae8f7a71
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'd7595de0b25e7064fd9e06dea5d0425536cef6dc':
aarch64: vp9: use alternative returns in the core loop filter function
This commit is a noop, see 62ea07d797
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e17567a831dede1f24e3a1a4c305a93012d7a8ce':
libilbc: support for latest git of libilbc
This commit is a noop, see 59af5383c1
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'ffe89e1edb0281ff65d1bda88253784e9283b717':
configure: Move mjpeg_vaapi_decoder dependency declarations to the right place
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'fbd1f7639d0142c391bec85d1d840c835210843f':
af_asyncts: Use llabs instead of labs for 64-bit variable
This commit is a noop, see a8fe8d6b4a
Merged-by: Clément Bœsch <u@pkh.me>
* commit '182cf170a544bce069c8690c90b49381150a1f10':
vp8: Return stream format information from parser
Return codes are adjusted to consume the whole packet in case of error
as the API does not allow returning AVERROR codes (a negative return
value is valid).
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'b6582b29277e00e5d49f400e58beefa5a21d83b8':
qsv: Add VC-1 decoder
See fb57bc6c34.
Merged for cosmetic purposes to reduce differences with libav.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'fea4dc05b41f5465bedc786b67966f204ec6150c':
vc1: Return stream format information from parser
This commit is a noop, see 4df6605da7
Merged-by: James Almer <jamrial@gmail.com>
* commit '0940b748bdba36c4894fc8ea6be631d821fdf578':
qsvdec: Only warn about unconsumed data if it happens more than once
Merged-by: James Almer <jamrial@gmail.com>
* commit '030d84fa2e35af0e77516735de35bf1a52371c86':
qsvdec: Pass field order information to libmfx
qsvdec: Pass the correct profile to libmfx
These commits are a noop, see 1f26a231bb
Merged-by: James Almer <jamrial@gmail.com>
* commit '3297577f3eac1c87d48dedd527942de2bd28e7a5':
mpegvideo: Return correct coded frame sizes from parser
This commit is a noop, see 309fe16a12
Merged-by: James Almer <jamrial@gmail.com>
* commit '3c9546dfafcdfe8e7860aff9ebbf609318220f29':
aarch64: vp9: Add NEON itxfm routines
This commit is a noop, see f43079e11c
Merged-by: James Almer <jamrial@gmail.com>
* commit '01348e411f962f5e4605d649fc9a47a54587ba8e':
avconv_opt: Consistently iterate through hwaccels array in all cases
Merged-by: James Almer <jamrial@gmail.com>
* commit '8ddfa5ae5ef64a25dd087d74954ebdb9081f0d67':
vf_drawtext: Drop wrong void* cast
This commit is a noop, see 4c96985af1
Merged-by: James Almer <jamrial@gmail.com>
* commit 'fcbdd605b5409103c3f4bfa063ea270f2229b125':
nut: Use correct function pointer casts instead of void*
This commit is a noop. Casts are not needed.
Merged-by: James Almer <jamrial@gmail.com>
* commit '3b50dbc51fb0978d09c1a5b83d4bf5a59d170e1e':
ratecontrol: Use correct function pointer casts instead of void*
Merged-by: James Almer <jamrial@gmail.com>
* commit 'dd299a2d6d4d1af9528ed35a8131c35946be5973':
arm: vp9: Add NEON loop filters
This commit is a noop, see 6bec60a683
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f7d183f08472e566a2e6b62a80e200a12670ed0e':
libxvid: Check return value of write() call
This commit is a noop, see 25f35df115
Merged-by: James Almer <jamrial@gmail.com>
* commit '12db2832e41aa71b5903ef7fa5c59c5473ded2c5':
libxvid: Require availability of mkstemp()
This commit is a noop. Our libxvid wrapper doesn't use mkstemp().
Merged-by: James Almer <jamrial@gmail.com>
* commit 'a67ae67083151f2f9595a1f2d17b601da19b939e':
arm: vp9: Add NEON itxfm routines
This commit is a noop, see b4dc7c341e
Merged-by: James Almer <jamrial@gmail.com>
* commit '0b37cd09a67c3ba4db044404b99c65a32b4ad932':
checkasm: add vp9dsp.itxfm_add tests.
This commit is a noop, see 0b227c6d47
Merged-by: James Almer <jamrial@gmail.com>
* commit 'fd0fae60372cddbe0bec8830d07e760195f80bad':
pthread_frame: Unreference hw_frames_ctx on per-thread codec contexts
This commit is a noop, see fb69a8e1f1
Merged-by: James Almer <jamrial@gmail.com>
* commit '11623217e3c9b859daee544e31acdd0821b61039':
arm: vp9mc: Use a different helper register for PIC loads
This commit is a noop, see 68caef9d48
Merged-by: James Almer <jamrial@gmail.com>
* commit '824e8c284054f323f854892d1b4739239ed1fdc7':
arm: Clear the gp register alias at the end of functions
This commit is a noop, see 86c5a23ee5
Merged-by: James Almer <jamrial@gmail.com>
* commit '6a62795d4051f435a9a2c59395d96913693922f8':
aarch64: h264idct: Use the offset parameter to movrel
This commit is a noop, see da5c8284c0
Merged-by: James Almer <jamrial@gmail.com>
* commit '557c1675cf0e803b2fee43b4c8b58433842c84d0':
arm: vp9mc: Minor adjustments from review of the aarch64 version
This commit is a noop, see 68caef9d48
Merged-by: James Almer <jamrial@gmail.com>
* commit '383d96aa2229f644d9bd77b821ed3a309da5e9fc':
aarch64: vp9: Add NEON optimizations of VP9 MC functions
This commit is a noop, see 1f7801c2bc
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c44a8a3eabcd6acd2ba79f32ec8a432e6ebe552c':
aarch64: Add an offset parameter to the movrel macro
This commit is a noop, see 7fe898dbb9
Merged-by: James Almer <jamrial@gmail.com>
* commit 'a4cfcddcb0f76e837d5abc06840c2b26c0e8aefc':
vp9: Make the subpel filters non-static
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit '98cae966c77875e26c5958206a6cfe7eba6269e8':
matroskaenc: write updated STREAMINFO metadata for FLAC streams if available
This commit is a noop, see 8c1342e631
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f4bf236338f6001736a4784b9c23de863057a583':
matroskaenc: fix muxing AAC streams when using aac_adtstoasc bsf
This commit is a noop. aac_adtstoasc bsf sends its extradata update
straight to codecpar->extradata.
This behavior violates the bsf API and should be fixed so this change
may then be applied.
Merged-by: James Almer <jamrial@gmail.com>
* commit '84f225684cd389747907381122c073aa1c8b6bf1':
pthread_frame: properly propagate the hw frame context across frame threads
This commit is a noop, see 98f89d615b.
Merged-by: James Almer <jamrial@gmail.com>
* commit '72a19f4013ec2c7f8581416f8ad4bf81df163fb6':
mpegaudiodsp: aarch64: Adjust function prototype after 2caa93b813
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c78495d1cdac6dd13786a7e5571b606604a360bd':
configure: Log name and parameters of all helper functions where it makes sense
Merged-by: James Almer <jamrial@gmail.com>
* commit '831005b2302cbeb377e3f00fd18c78928bcec185':
configure: Log correct test name and use correct filter when testing objective C flags
Merged-by: James Almer <jamrial@gmail.com>
* commit 'fe7bc1f16abaefe66d8a20f734ca3eb8a4ce4d43':
configure: Do not unconditionally check for (and enable) xlib
Merged-by: James Almer <jamrial@gmail.com>
The value must be identical between slices, since mbaff depends on
picture_structure and sps, both of which are checked to be identical
to the first slice before this point.
In practice, this silences some tsan warnings in fate-h264.
This fixes race conditions reported by tsan in fate-lagarith. The races
were because each thread's LagarithContext::avctx was set to the first
thread's AVCodecContext.
Otherwise all thread's private contexts have the avctx pointer set to
the AVCodecContext of the first thread, which means all writes to
ctx->avctx->* (in e.g. read_header) are effectively race conditions.
Fixes fate-dnxhd under tsan.
Adding an MOV format option to turn on/off the editlist supporting code, introduced in ca6cae73db
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'd1a91ebe4990001e0800ee9ac54ed2207e4f56ff':
configure: Print list of enabled programs
This commit is mostly a noop, see 832b4a4a43
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'a3483f79933e8f1fd99d524e3218688e14c59150':
avconv: Drop stray leftover debug output
This commit is a noop, see a283665693
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '59d2b00d201935c16408a2917957d89a170fe58f':
configure: Add --quiet command line parameter to suppress informative output
The license assignment is moved out of the quiet condition to make sure
it ends up in config.h
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'de6e2ff3ddf506d5b487c2f226cea73e095ad6d1':
mov: Read multiple stsd from DV
This commit is a noop, see a765ba647d
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '47a795727f5433f5238a8a244cf181f61ea5af2c':
hevc: Support extradata changes from multiple stsd
This commit is a noop, see 25fcbf7a84
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '2fe30b4743c0f4c3bdf37b91ae534cafa85e4036':
hevc: Allow parsing external extradata buffers
This commit is a noop as it matches FFmpeg state.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '5be21531119d7a97ebc706800d1608272ee5a507':
hevc: Move hevc_decode_extradata before frame decoding
This commit is a noop, hevc_decode_extradata() is already above
hevc_decode_frame().
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'bed2c4b2652b1412b584e5545d6dd2ef8c613be0':
lavc: Add hevc main10 profile to avconv cli
This commit is a noop, see 271afd632f
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '0361e4dcb4d394c88c33364415a3b8fe315b67d1':
h264_qpel: x86: Move function with only one instance out of template macro
Note: warning is present with clang.
Merged-by: Clément Bœsch <cboesch@gopro.com>
This is more robust in case some change or corner case causes them to be
dereferenced before being set
Fixes CID1396274, CID1396275
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '88f0cf8cd30c8ea283430e6710a7bd98bb9c0301':
avplay: Correct function pointer assignments in options array
This commit is a noop, see a9a1bc56ab
Merged-by: Clément Bœsch <u@pkh.me>
* commit '943533d64c7fa7a1b2fc9559e67652c349d21d51':
avconv: Correct function pointer assignments in options array
This commit is a noop, see 4c96985af1
Merged-by: Clément Bœsch <u@pkh.me>
* commit '43de8b328b62cf21ec176c3989065168da471a5f':
lzf: update pointer p after realloc
This commit is a noop, see bb6a7b6f75
Merged-by: Clément Bœsch <u@pkh.me>
* commit '00aeedd84105a17f414185bd33ecadebeddb3a27':
qsv{dec,enc}: use a struct as a memory id with internal memory allocator
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit '404e51478ecad060249d5b9bee6ab39a8a9d8c1c':
qsv{dec,enc}: always use an internal mfxFrameSurface1
Minor fixups for differences in the QSV encoder because of a53cc.
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit '8ea15afbf2c1ec89b5d4bac1f0b8345e4b906a5d':
hwcontext_qsv: transfer data through the child context when VPP fails
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit 'b91ce4860054430d3712deb0d9487cac2fcb7d68':
hwcontext_qsv: do not fail when download/upload VPP session creation fails
Merged-by: Mark Thompson <sw@jkqxz.net>
This is an example, people will copy and use this. The maximum supported is quite
unreasonable as a default choice
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'fabfbfe5710050812147f93a351a53fdda56ff8c':
dxva2: fix surface selection when compiled with both d3d11va and dxva2
This commit is a noop, see 153b36fc62
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'db0b3dccb3842de134721e8d5c275f56d384340d':
libx265: Add option to force IDR frames
This commit is a noop, see 8a8902f221
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '3cba09e5228c889d63814dc43bc68f15c9dbac77':
x86: Drop stray semicolons after function definitions
This commit is a noop, they are already fixed in FFmpeg.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'd1ef1b9eaa45043ea5df5a004fb37243e05da61d':
configure: Silence lld-link when getting the version number
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '392caa65df3efa8b2d48a80f08a6af4892c61c08':
arm: vp9mc: Insert a literal pool at the middle of the file
This commit is a noop, see 68caef9d48
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '99434f4df81b6801b2b535d5b9143305595784f6':
float_dsp: Have implementation match function pointer prototype
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '6354957a95022864746180525680cca872ab0e0a':
dnxhdenc: Have function pointer prototype match implementation
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'c778eb15b89d875cb246b18f65b3b4321cb1e7d6':
pixblockdsp: Have function pointer prototype match implementation
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '99ddeddc7fc996c0c1e842112928490e78542bd5':
ituh263dec: Have function signature match across declaration and definition
This commit is a noop, see 2d2b363c65
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '67c65e461cb073d61ffbc78845d4a3d8f14bf481':
vf_hwupload_cuda: Fix build error
This commit is a noop, see 78e871ebbc
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '13fcdfb976038f63b9f753e2ebcc8e04d7c7abc2':
svq3: Drop unused function dctcoef_get()
This commit is a noop, see 1e298e7724
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'ee59f0540875ab42496af2aacddd942757707683':
intrax8: Have function signature match across declaration and definition
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '1a469a5e423bdad779b8534247dea8cc86169b88':
options_table: Remove a now unnecessary include of config.h
This commit is a noop, see 76f43cbe26
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'ffbd1d2b0002576ef0d976a41ff959c635373fdc':
arm: vp9: Add NEON optimizations of VP9 MC functions
This commit is a noop, see 68caef9d48
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '2e55e26b40e269816bba54da7d0e03955731b8fe':
vp9: Flip the order of arguments in MC functions
This commit is a noop, it was made to match our prototypes.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '7e2561fa8313982aa21f7657953eedeeb33b210d':
lavfi: Use ff_get_video_buffer in all filters using hwframes
vf_hwupload_cuda: Fix build error
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
* commit '7433feb82f75827884d909de34d341a1c4401d4a':
lavfi: Make default get_video_buffer work with hardware frames
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
This conflict with the DJGPP libc math.h which includes a PI macro (to
M_PI).
We cannot make DJGPP POSIX only (using -D_POSIX_SOURCE) to avoid this
kind of symbols conflicts due to the lack of both posix_memalign and
memalign (DJGPP non standard function) in that POSIX mode. We currently
rely on memalign for aligned heap allocation.
This conflict with the DJGPP libc which includes a pow2 function¹
We cannot make DJGPP POSIX only (using -D_POSIX_SOURCE) to avoid this
kind of symbols conflicts due to the lack of both posix_memalign and
memalign (DJGPP non standard function) in that POSIX mode. We currently
rely on memalign for aligned heap allocation.
[1]: http://www.delorie.com/djgpp/doc/libc-2.02/libc_536.html
This conflict with the DJGPP libc which includes a pow2 function¹
We cannot make DJGPP POSIX only (using -D_POSIX_SOURCE) to avoid this
kind of symbols conflicts due to the lack of both posix_memalign and
memalign (DJGPP non standard function) in that POSIX mode. We currently
rely on memalign for aligned heap allocation.
[1]: http://www.delorie.com/djgpp/doc/libc-2.02/libc_536.html
* commit '39cea6570c11a49b64b2ec8d71e218db03b4c742':
aactab: Move extern keyword to the front of array declarations
Merged-by: Clément Bœsch <u@pkh.me>
* commit '85baef4ff1512bcc2544928bfa5f42072903a691':
vf_drawtext: Move static keyword to beginning of variable declaration
This commit is mostly a noop, see:
d9e2aceb7f6d7aa437e1
Merged-by: Clément Bœsch <u@pkh.me>
* commit '636515c324facaa14ccd8ab0732740a240a31ba9':
examples/decode_video: remove a stray unrelated comment
This commit is a noop, see 8c4753f7f5
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5b4d7ac7ae5d821cfa6ab89f8eab4d31851ef32c':
examples/encode_video: use the AVFrame API for allocating the frame
Merged-by: Clément Bœsch <u@pkh.me>
* commit '7b1f03477f1a43d2261fbd83e50a4ad90c7f806d':
examples/avcodec: split the remaining two examples into separate files
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f5df897c4b61985e3afc89ba1290649712ff438e':
examples/avcodec: split audio decoding into a separate example
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f76698e759a08e8d3b629c06edb0439f474e7fee':
examples/encode_audio: use the AVFrame API for allocating the data
Merged-by: Clément Bœsch <u@pkh.me>
* commit '40aaa8dadfd1c69ff4460d04750e1403b5535a6d':
examples/avcodec: split audio encoding into a separate example
Merged-by: Clément Bœsch <u@pkh.me>
Get rid of the "ret" variable, and always use err. Report the packet as
consumed if err is unset. This should be equivalent to the old code,
which obviously required err=0 for p->result>=0 (and otherwise,
p->result must have had the value err was last set to). The code block
added by commit 32a5b63126 is also not needed anymore, because the new
code strictly returns err if it's >=0.
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Intra-only codecs should either be able to read these items from the
bitstream, or they should be set upon codec initialization. In both
cases, syncing these items at runtime is unnecessary.
In practice, this fixes race conditions for decoders that read these
values from the bitstream.
If ret is NULL, a dummy common holder is created to hold *all* the
parallel function returns, which gets written concurrently. This commit
simplify the whole logic by simply not writing to that holder when not
set.
Needed for the C+11 atomics. Also change add_cxxflags to check_cxxflags.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
refer to SPEC:
Annex E. The FLV File Format said:
E.3 TheFLVFileBody have a table:
Field Type Comment
PreviousTagSize0 UI32 Always 0
Reviewed-by: Bela Bodecs <bodecsb@vivanet.hu>
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
adding demuxer and other logs should be easy
This forces single threaded decoding for simplicity
It also requires pthreads, this could be avoided either with
some lockless tricks or simply by assuming av_log would never be called from
another thread.
Fixes Ticket5521
Previous version reviewed by Stefano
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '064f19f39e2f17927278c6ad8fe884a5b92310d6':
avconv: support parsing bitstream filter options
This commit is a noop, see 5ef1959080
Merged-by: James Almer <jamrial@gmail.com>
* commit 'ecd2ec69ce10e13f6ede353d2def7ce9f45c1a7d':
mov: Evaluate the movie display matrix
This commit is a noop, see 7010ebdf1f
Merged-by: James Almer <jamrial@gmail.com>
* commit 'b90c8a3d08e3f9ad4de1253376d2d1d93abb8b8c':
fate: Add tests for mov display matrix
Adapted to use ffprobe -show_entries
Merged-by: James Almer <jamrial@gmail.com>
* commit '7d308bf84bda78d47c01439ff625bb06624991a7':
avprobe: Add -show_stream_entry to get a single stream property
This commit is a noop, we have a generic -show_entry option.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '218ed7250c103a975e874fb16e8e5941f4cbe223':
openssl: Allow newer TLS versions than TLSv1
This commit is a noop, see e8634fb92e
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'dad7514f9ec8a8c5e44d70fcfbbcedeff16f7e13':
xcb: Add all the libraries to the link line explicitly
This commit is a noop. It appears we already link against the xcb shape
library since 54170a33c2.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'c541a44e029e8a4f21db028c34fee3ad1c10a409':
Revert "rtmpproto: Don't include a client version in the unencrypted C1 handshake"
Merged-by: Clément Bœsch <u@pkh.me>
* commit '801ac7156d3efb8e088fb6024f568eb36a293887':
qsv: Be informative when reporting that no data has been consumed
Merged-by: Clément Bœsch <u@pkh.me>
* commit '30015305f3b523ed7640f2c3c58b017140533c58':
Use avpriv_request_sample() where appropriate
Only the roqvideo chunk is merged because we actually support 24bpp
flic, see 5781c983d8.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '07cac07c0c0360d67e73a7472214c79d6c520a4b':
dash: Use correct ISO C scanf conversion specifier
This commit is a noop: the use of SCN (scanf) format is wrong here.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3ec6f855d0f21d90a0494fb798c4cf203fdb3db0':
srt: Adjust signedness of sscanf format strings
This commit is a noop, a different fix is included in the big -Wformat
patch under review
(http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209239.html)
Merged-by: Clément Bœsch <u@pkh.me>
* commit '7a2b2b6a92c4b528ecb640790eca0aa790d858f4':
dxtory: Drop nonsense ISO C printf conversion specifiers for standard types
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'c454dfcff90f0ed39c7b0d4e85664986a8b4476c':
Use ISO C printf conversion specifiers where appropriate
This commit is a noop, an equivalent patch is currently under review on
the mailing-list: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209239.html
Merged-by: Clément Bœsch <u@pkh.me>
Could lead to random behavior. This possibly happened due to commit
32a5b63126. This should/could probably be simplified, but for no apply
a minimal fix to quell the errors.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
async_mutex has is used in a very strange but intentional way: it is
locked by default, and unlocked only in regions that can be run
concurrently.
If the user was calling API functions to the same context from different
threads (in a safe way), this could unintentionally unlock the mutex on
a different thread than the previous lock operation. It's not allowed by
the pthread API.
Fix this by emulating a binary semaphore using a mutex and condition
variable. (Posix semaphores are not available on all platforms.)
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
The old "API" that signaled rotation as a metadata value has been
replaced by DISPLAYMATRIX side data quite a while ago.
There is no reason to make muxers/demuxers/API users support both. In
addition, the metadata API is dangerous, as user tags could "leak" into
it, creating unintended features or bugs.
ffmpeg CLI has to be updated to use the new API. In particular, we must
not allow to leak the "rotate" tag into the muxer. Some muxers will
catch this properly (like mov), but others (like mkv) can add it as
generic tag. Note applications, which use libavformat and assume the
old rotate API, will interpret such "rotate" user tags as rotate
metadata (which it is not), and incorrectly rotate the video.
The ffmpeg/ffplay tools drop the use of the old API for muxing and
demuxing, as all muxers/demuxers support the new API. This will mean
that the tools will not mistakenly interpret per-track "rotate" user
tags as rotate metadata. It will _not_ be treated as regression.
Unfortunately, hacks have been added, that allow the user to override
rotation by setting metadata explicitly, e.g. via
-metadata:s:v:0 rotate=0
See references to trac #4560. fate-filter-meta-4560-rotate0 tests this.
It's easier to adjust the hack for supporting it than arguing for its
removal, so ffmpeg CLI now explicitly catches this case, and essentially
replaces the "rotate" value with a display matrix side data. (It would
be easier for both user and implementation to create an explicit option
for rotation.)
When the code under FF_API_OLD_ROTATE_API is disabled, one FATE
reference file has to be updated (because "rotate" is not exported
anymore).
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Squelches the following compiler warnings:
libavcodec/opusenc.c:1051:16: warning: format specifies type 'long' but
the argument has type 'long long' [-Wformat]
avctx->bit_rate/1000, clipped_rate/1000);
^~~~~~~~~~~~~~~~~~~~
libavcodec/opusenc.c:1051:38: warning: format specifies type 'long' but
the argument has type 'long long' [-Wformat]
avctx->bit_rate/1000, clipped_rate/1000);
^~~~~~~~~~~~~~~~~
This was skipped in c17563c5d3 because
it depended on the filter setup merge, but was forgotten after that
actually happened.
Fixes hwaccel fate for stream size change tests.
Changes to the parsing code originally committed to mpegvideo_parser.c
in 73fb23dc5a.
Required by some samples, like PVA_test-partial.pva
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit 'fbe425c8d29e473a8f69ae2dc52b1a10b77f3b44':
hap: Adjust printf length modifiers to match variable types
This commit is a noop, see 5a51ca2da7
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f22363c72968f1a1fc4881d8695ec7068b0aa03c':
openssl: Avoid double semicolons after the GET_BIO_DATA macro
This commit is a noop, see fc83de7e1d
Merged-by: Clément Bœsch <u@pkh.me>
* commit '99aeae20de4d09ea313fdc619d4e2df825155e62':
scale_npp: fix passthrough mode
This commit is a noop, see f524275ef9
Merged-by: Clément Bœsch <u@pkh.me>
* commit '754b20d7ebccbe8d316b12128c8cb433d5a516ac':
vaapi_h264: fix RefPicList[] field flags.
This commit is a noop, see 88325c2e0b
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'ee050797664c7c74cae262ffab05006b55d47a11':
openssl: Support version 1.1.0.
This commit is mostly a noop, see 798c6ecce5
Included the simplifications by Martin Storsjö and fixed the
GET_BIO_DATA() macro to prevent a warning after the simplifications.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '2f806622e1270d3ed1d41a53049a19673dafbe70':
bktr: Use memset(0) instead of zero initialization for struct sigaction
Merged-by: Clément Bœsch <u@pkh.me>
* commit '6d5636ad9ab6bd9bedf902051d88b7044385f88b':
hevc: x86: Add add_residual() SIMD optimizations
See a6af4bf64d
This merge is only cosmetics (renames, space shuffling, etc).
The functionnal changes in the ASM are *not* merged:
- unrolling with %rep is kept
- ADD_RES_MMX_4_8 is left untouched: this needs investigation
Merged-by: Clément Bœsch <u@pkh.me>
* commit '043b0b9fb1481053b712d06d2c5b772f1845b72b':
Replace leftover uses of -aframes|-dframes|-vframes with -frames:a|d|v
The merge also includes all our own occurences.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '4b07ebf1eb13561492f7e3c30a67f34415016b3e':
mov: Update colr values
Mostly noop, see a3cab3d433
Only the use of av_color_{primaries,transfer,space}_name() is merged.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '59c90097a0eff0dc81fbec15b8900c929859d1e7':
hevc: factor out a repeated condition
This commit is a noop. It doesn't apply as our codebase has diverged
too much.
Merged-by: James Almer <jamrial@gmail.com>
* commit '096a8effa3f8f3455292c958c3ed07e798def7bd':
lavf: check that the codec is supported by extract_extradata
This commit is a noop. The code it changes was reverted.
See 40fa9d416a
Merged-by: James Almer <jamrial@gmail.com>
This reverts commit 1c193ac1f9, reversing
changes made to 7ebc9f8df4.
Several FATE tests started failing after this merge, so it's reverted
until it can be properly fixed.
* commit '788544ff0ed6fe67fda80ad6d3a0796ace035584':
audiodsp: x86: Remove pointless header file
This commit is a noop, see 6ec3dc97fc
Merged-by: James Almer <jamrial@gmail.com>
* commit 'b89804da9bad2d94dd95bf20ac6187447e9c17e9':
x86: videodsp: Add parentheses to expression to work around warning
Merged-by: James Almer <jamrial@gmail.com>
* commit 'da4f8c8e35a867f2d9fed0fb75e16c81ab968637':
fate: Update filter-pixfmts-scale gbrap12le hash missing from be9dba5c8a
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'be9dba5c8abc6ecf0b8ee4ccb11c7850327fcf8d':
swscale: Properly load alpha for planar rgb
This commit is a noop, see
4170a44bbcdf36257a53
Merged-by: James Almer <jamrial@gmail.com>
* commit '58224dc5f3d4fea40a8d55cca87291a960c11622':
ppc: avcodec: Drop silly "_ppc" suffixes from files in ppc subdirectories
Merged-by: James Almer <jamrial@gmail.com>
* commit '0cf86fabfa5820596cca2cfead63c6f8df76c3f2':
vaapi_encode: Write sequence header as extradata
This commit is a noop. It has already been cherry-picked in
51020adcec
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c91d6a33f872574c95c8784277cf60ffcf6bff4f':
checkasm: aarch64: Add filler args to make sure all parameters are passed on the stack
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f1b3e131385176c3c9d9783b25047856a0dcebf6':
checkasm: aarch64: Clobber the stack before calling functions
Merged-by: James Almer <jamrial@gmail.com>
* commit 'a05cc56124b4f1237f6355784de821e3290ddb44':
checkasm: arm/aarch64: Fix the amount of space reserved for stack parameters
Merged-by: James Almer <jamrial@gmail.com>
* commit '8e2ea691351c5079cdab245ff7bfa5c0f3e3bfe4':
lavf: use the new bitstream filter for extracting extradata
Merged-by: James Almer <jamrial@gmail.com>
* commit '89b35a139e838deeb32ec20d8d034c81014401d0':
lavc: add a bitstream filter for extracting extradata from packets
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f6e2f8a9ffda2247bffba991450990d075ea68e3':
hevcdec: move parameter set parsing into a separate header
Merged-by: James Almer <jamrial@gmail.com>
* commit '150c896a9e46b23b97debb0a5f66fbaeaa32f153':
hevcdec: split ff_hevc_diag_scan* declarations into a separate header
Merged-by: James Almer <jamrial@gmail.com>
* commit '645c6ff4231a75a71db58c8e6d06346068d2f949':
hevcdec: drop the prototype of a non-existing function
This commit is a noop. The prototype in question is not in our tree.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c359d624d3efc3fd1d83210d78c4152bd329b765':
hevcdec: move decoder-independent declarations into a separate header
Merged-by: James Almer <jamrial@gmail.com>
* commit '6c31ba226968f12f898120dbb928dab34e03782b':
avformat/matroska: fix MatroskaVideoFieldOrder enum values
This commit is a noop, see dc781459cc
Merged-by: Clément Bœsch <u@pkh.me>
* commit '20b75970e43a030f959b17ff2dfd561174b6f24e':
file protocol: handle the file: protocol string in file_check
This commit is a noop, see 77015443a8
Merged-by: Clément Bœsch <u@pkh.me>
* commit '7d8d726be7dc46343ab1c98c339c1ed44bcb07c1':
rtmpproto: Don't include a client version in the unencrypted C1 handshake
Merged-by: Clément Bœsch <u@pkh.me>
* commit '9f23f77a532ca9c2b7dc4b5328bc413e4f6f5b56':
rtmpproto: Don't include the libavformat version as "clientid"
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'c9527bf3444c5332fa04931d32997308784fc862':
Make the RELEASE file match with the most recent tag
This commit is noop.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '881477c77bb10c3c62fda111b0f1f3554968bc78':
swscale: Add the GBRAP12 output
Add GBRAP12 pixel format support
swscale: Enable GBRP12 output
swscale: x86: Add some forgotten 12-bit planar YUV cases
swscale: Add input support for 12-bit formats
This merge is noop, these commits are recrafted cherry-picks from
FFmpeg.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '1e93aa69a60815d1407a6c34d8da3f83ab193ad5':
Add GBRP12 pixel format support
This commit is a noop, see e9757066e1
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e7e5be8635c1cf0588d2a07e59374135de6da55a':
APIchanges: Expand the name of recently added pixel formats
This commit is a noop, we don't have this entry.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'eb542106029a9b28b4f76ff7c181eb4f542da9c4':
swscale: Add missing yuv444p12 swapping
This commit is a noop, these pixel formats were introduced long ago and
present in the switch case.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'cbd84b8a51aa656d71b7d6ed44bd89041ff081a8':
nvenc: Fix error log
This commit is a noop, the error message is correct in FFmpeg.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'da2848375a2e2121dad9f1e8cbd0ead4e3bf77d6':
nvenc: Force high_444 profile for 444 input
This commit is a noop, see 20abda6b62
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e4128c08d786eb5513578e8c6063671ba03226ab':
Revert "hevc: x86: Refactor IDCT macro declarations"
So apparently this was technically correct be reverted due to
authorship. Reverted as well in FFmpeg for now...
See http://lists.libav.org/pipermail/libav-devel/2016-October/079560.html
Merged-by: Clément Bœsch <u@pkh.me>
* commit '20abcaa273a6e77d0a2e1a98c643c73562c6f8f2':
configure: #include stdint.h as part of libxavs test
This commit is a noop, see 20c4fb2e01
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'be630b1e08ebe8f766b1798accd6b8e5e096f5aa':
d3d11va: Use the proper decoding slice index
This commit is a noop, see 9b462a0b9d
Merged-by: Clément Bœsch <u@pkh.me>
* commit '715f139c9bd407ef7f4d1f564ad683140ec61e6d': (23 commits)
vp9lpf/x86: make filter_16_h work on 32-bit.
vp9lpf/x86: make filter_48/84/88_h work on 32-bit.
vp9lpf/x86: make filter_44_h work on 32-bit.
vp9lpf/x86: make filter_16_v work on 32-bit.
vp9lpf/x86: make filter_48/84_v work on 32-bit.
vp9lpf/x86: make filter_88_v work on 32-bit.
vp9lpf/x86: make filter_44_v work on 32-bit.
vp9lpf/x86: save one register in SIGN_ADD/SUB.
vp9lpf/x86: store unpacked intermediates for filter6/14 on stack.
vp9lpf/x86: move variable assigned inside macro branch.
vp9lpf/x86: simplify ABSSUM_CMP by inverting the comparison meaning.
vp9lpf/x86: remove unused register from ABSSUB_CMP macro.
vp9lpf/x86: slightly simplify 44/48/84/88 h stores.
vp9lpf/x86: make cglobal statement more conservative in register allocation.
vp9lpf/x86: save one register in loopfilter surface coverage.
vp9lpf/x86: add ff_vp9_loop_filter_[vh]_44_16_{sse2,ssse3,avx}.
vp9lpf/x86: add ff_vp9_loop_filter_h_{48,84}_16_{sse2,ssse3,avx}().
vp9lpf/x86: add an SSE2 version of vp9_loop_filter_[vh]_88_16
vp9lpf/x86: add ff_vp9_loop_filter_[vh]_88_16_{ssse3,avx}.
vp9lpf/x86: add ff_vp9_loop_filter_[vh]_16_16_sse2().
...
All these commits are cherry-picks from FFmpeg. Maybe some slight
differences sneaked in but the Libav codebase still differs too much
with our own to make a proper diff. This merge is a noop.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '497c087939e32b26b792515d2dbc7e22561203f7':
avidec: Set palette alpha as fully opaque
This commit is a noop, see 64cafe340b
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'bad4aad4037f59ba0ad656164be9ab8f7a0fa2d4':
avidec: Do not special case palette on big-endian
This commit is a noop, see 64cafe340b
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5a5df90d9c05d86d9b0564b8b40b6d64a324df5e':
vaapi_h265: Add main 10 encode support
This commit is a noop, see b9514756ba
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'eaaaabf6c93321cdb78bf61dc383cf515ec12e07':
hwcontext_vaapi: Enable P010 support
This commit is a noop, see 7e0623b70b
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5cc0057f4910c8c72421b812c8f337ef6c43696c':
lavu: remove the custom atomic API
This commit is a noop. The removal is postponed until all usages in
FFmpeg are dropped as well. A patchset is on discussion on the
mailing-list:
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209003.html
Merged-by: Clément Bœsch <u@pkh.me>
This supports retrieving the device from a provided hw_frames_ctx, and
automatically creating a hw_frames_ctx if hw_device_ctx is set.
The old API is not deprecated yet. The user can still use
av_vdpau_bind_context() (with or without setting hw_frames_ctx), or use
the API before that by allocating and setting hwaccel_context manually.
Cherry-picked from Libav commit 1a7ddba5.
(Adds missing APIchanges entry to the Libav version.)
Reviewed-by: Mark Thompson <sw@jkqxz.net>
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>
libavcodec/vaapi.h:58:1: warning: attribute 'deprecated' is ignored, place it after "struct" to apply attribute to type declaration [-Wignored-attributes]
(cherry picked from commit ed6a891c36)
Signed-off-by: Mark Thompson <sw@jkqxz.net>
* commit '59c70227405c214b29971e6272f3a3ff6fcce3d0':
pthread_frame: use atomics for frame progress
This commit is a noop, see b6587421c7
Merged-by: Clément Bœsch <u@pkh.me>
* commit '64a31b2854c589e4f27cd68ebe3bcceb915704e5':
pthread_frame: use atomics for PerThreadContext.state
This commit is a noop, see 7492626932
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'db2733256db323e4b88a34b135320f33274148e2':
pthread_frame: use a thread-safe way for signalling threads to die
This commit is a noop, see 4845f0720e
Merged-by: Clément Bœsch <u@pkh.me>
USE_ATOMICS is only set if there is no thread implementation enabled, in
which case you can't expect any lock mechanism from FFmpeg.
This is also conflicting with the incoming use of stdatomic.
* commit 'eb34d40354e2474517c9b9bd787e0dadc89c2a81':
Add a compat dummy stdatomic.h used when threading is disabled
Add a compat stdatomic.h implementation based on pthreads
Add a compat stdatomic.h implementation based on suncc atomics
Add a compat stdatomic.h implementation based on windows atomics
Add a compat stdatomic.h implementation based on GCC atomics
This merge is a noop, see:
41e891e89e Add a compat dummy stdatomic.h used when threading is disabled
74b5f10862 Add a compat stdatomic.h implementation based on pthreads
70faadc826 Add a compat stdatomic.h implementation based on suncc atomics
c91e72ed52 Add a compat stdatomic.h implementation based on windows atomics
3359eede8f Add a compat stdatomic.h implementation based on GCC atomics
Merged-by: Clément Bœsch <u@pkh.me>
* commit '13f5d2bf75b95a0bfdb9940a5e359a719e242bed':
configure: check for stdatomic.h
This commit is a noop, see 6a4e24280d
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'b015872c0d0823e70776e98b865509ec1287e2f6':
huffyuvdsp: Enable the altivec code for PPC little-endian as well
This commit is a noop, see 902ce2a6c4 and
libavcodec/ppc/lossless_videodsp_altivec.c
Merged-by: Clément Bœsch <u@pkh.me>
* commit '1d25a86902946dbc80bb3a38e61755181ca3af7b':
huffyuvdsp: Reenable PPC optimizations
This commit is a noop, see 6596b34954
Merged-by: Clément Bœsch <u@pkh.me>
* commit '22c3ab18646924ce24dc6017a9e882ff69689e40':
checkasm: Add test for huffyuvdsp add_bytes
huffyuvdsp is renamed to llviddsp to be consistent with our codebase.
Note: af607b7e07 wasn't actually required for this test since this
commit is not actually testing huffyuvdsp.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f6772e9bf8251d3943f52f6f34d97d2ce6c4b8af':
avconv: make sure the filtergraph is freed on init failure
This commit is a noop, see 16abc10b09
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'd10102d23c9467d4eb84f58e0cd12be284b982f6':
avconv: set the encoding framerate when the output is CFR
This commit is a noop, see 8db301dead
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5bf2454e7cb03609b3ec1a3cf4c22427fe5f8e36':
h264dec: support broken files with mp4 extradata/annex b data
This commit is a noop, see 93b89868e1
The sample pointed out on
https://github.com/HandBrake/HandBrake/issues/339 decodes fine in
FFmpeg.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '2124711b950b03c582a119c75f52a87acc32d6ec':
hwcontext_vaapi: add a quirk for the missing MemoryType attribute
This commit is a noop, see 775a8477b7
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'a9ba59591ed509fb7e6decfde8da4cbfd4ddf4b8':
ac3dsp: Add some special-case handling for the C downmix function
Merged-by: Clément Bœsch <u@pkh.me>
* commit '8ea35af7620e4f73f9e8c072e1c0fac9a04ec161':
avio: add a new flag for marking streams seekable by timestamp
Merged-by: James Almer <jamrial@gmail.com>
* commit '8d1267932ca9c2e343ef303349101bab6681d02e':
x86/h264_weight: use appropriate register size for weight parameters
This commit is a noop, see 5ae0ad001a
Merged-by: James Almer <jamrial@gmail.com>
* commit '2caa93b813adc5dbb7771dfe615da826a2947d18':
mpegaudiodsp: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit '15b4f494fc6bddb8178fdb5aed18b420efc75e22':
mss*: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit 'a339e919cad1ab0125948f0dd9d49f6cb590db89':
ea: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit 'ba479f3daafc7e4359ec1212164569ebe59f0bb7':
hevc: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit 'e4a94d8b36c48d95a7d412c40d7b558422ff659c':
h264chroma: Change type of stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit '2ec9fa5ec60dcd10e1cb10d8b4e4437e634ea428':
idct: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
Aliased compressed AAC bytes are almost certainly not meaningful SBR
data. In the wild this causes harsh artifacts switching HE-AAC streams
that don't have SBR headers aligned with segment boundaries.
Turning off SBR falls back to a default set of upsampling parameters
that can function as a sort of error concealment. This is consistent
with how the decoder handles other sorts of errors.
* commit '956a54129db522998a5abae869568dae2c9774cb':
vaapi_h264: Set max_num_ref_frames to 1 when not using B frames
vaapi_encode: Sync to input surface rather than output
vaapi_encode: Check packed header capabilities
vaapi_encode: Refactor initialisation
This merge is a noop, see:
ee1d04f970 vaapi_h264: Set max_num_ref_frames to 1 when not using B frames
94f446c628 vaapi_encode: Sync to input surface rather than output
478a4b7e6d vaapi_encode: Check packed header capabilities
c8241e730f vaapi_encode: Refactor initialisation
Merged-by: Clément Bœsch <u@pkh.me>
* commit '67d28f4a0fbb52d0734ca3682b85035e96d294fb':
examples/output: switch to the new encoding API
This commit is a noop, our examples are different. Still, we need to
update them to the new API, so doc/libav-merge.txt is updated.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'de2ae3c1fae5a2eb539b9abd7bc2a9ca8c286ff0':
lavc: add clobber tests for the new encoding/decoding API
The merge only re-order what we already have.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '6c09af7e46a5a1ada67ffe832f7895cf2749130b':
APIchanges: fix a typo in the version number
This commit is a noop (typo is not present in FFmpeg).
Merged-by: Clément Bœsch <u@pkh.me>
* commit '0e8d1fc1f013eb805a7b66656d9452bcbca36d22':
lavu: Bump version for the 12bit Planar YUV support
pixfmt: Add yuv444p12 pixel format
pixfmt: Add yuv422p12 pixel format
pixfmt: Add yuv420p12 pixel format
This merge is a noop, we already have all these pixel formats.
Merged-by: Clément Bœsch <u@pkh.me>
It was done on a whim because of the FATE header check and was actually
meant to be removed before pushing.
Also, nobody in review spotted it.
Reviewed-by: wm4
* commit '2b5b1e1e9b89063d352e2efed014f9d761b85032':
swscale: Rename is9_OR_10 to match what it does
This commit is a noop. We use isNBPS() in these places instead since
d736b52a04. is9_15BPS() wouldn't be a good name in our codebase due to
supporting only up to 14 (see 2ea585b8e3).
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e87a501e7d03ac68b58520108fe24ad9d0b36765':
swscale: Update bitdepth range check
This commit is a noop.
Up to 14 bits is supported since fa36f33422. This commits pushes the
limit to 15 bits but we don't seem to have pixel formats that enters in
that category.
12:03 <ubitux> so what's your opinion? should we move to 15 even if unused currently to make it consistent with libav and the function names, or keep our 14 suggesting there might be an issue with 15?
12:05 <ubitux> (functions are called hScale8To15_c, hScale16To15_c, ff_hscale8to15, ...)
12:06 <michaelni> I prefer to keep 14 until theres a case that allows us to test this and i suspect it will not work with 15 at least not all the code
Merged-by: Clément Bœsch <u@pkh.me>
libavcodec now automatically serializes decoding for hwaccels which
are not thread-safe. This means API users, which rely on the libavcodec
native software fallback mechanism, can now simply enable threading
without running into problems.
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>
This improves commit 59c7022740.
In ff_thread_report_progress(), the fast code path can load
progress[field] with the relaxed memory order, and the slow code path
can store progress[field] with the release memory order. These changes
are mainly intended to avoid confusion when one inspects the source code.
They are unlikely to have measurable performance improvement.
ff_thread_report_progress() and ff_thread_await_progress() form a pair.
ff_thread_await_progress() reads progress[field] with the acquire memory
order (in the fast code path). Therefore, one expects to see
ff_thread_report_progress() write progress[field] with the matching
release memory order.
In the fast code path in ff_thread_report_progress(), the atomic load of
progress[field] doesn't need the acquire memory order because the
calling thread is trying to make the data it just decoded visible to the
other threads, rather than trying to read the data decoded by other
threads.
In ff_thread_get_buffer(), initialize progress[0] and progress[1] using
atomic_init().
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Merges Libav commit 343e2833.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
When decoding with threads enabled, the get_format callback will be
called with one of the per-thread codec contexts rather than with the
outer context. If a hwaccel is in use too, this will add a reference
to the hardware frames context on that codec context, which will then
propagate to all of the other per-thread contexts for decoding. Once
the decoder finishes, however, the per-thread contexts are not freed
normally, so these references leak.
Merges Libav commit fd0fae60.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
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>
This filter does not implement all features of MPEG7. Missing features:
- compression of signature files
- work only on (cropped) parts of the video
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '70de2ea4261f860457a04e3d0c58c5543f403325':
nvenc: Extended rate-control support as provided by SDK 7
This commit is a noop, see facc19ef06
Merged-by: Clément Bœsch <u@pkh.me>
* commit '358c887a9fa0fb2e7ce089eaea71ab924a3e47a7':
nvenc: Add support for high bitdepth
This commit is a noop, see d1bf8a3aa8
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e02e2515b24bfc37ede6ca1744696230be55e50b':
nvenc: Add some easier to understand presets that match x264 terminology
This commit is a noop, see a81b000a39 and
faffff88c2.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '352741b5ead1543d775ccf6040f33023e4491186':
nvenc: Make sure that enum and array index match
This commit is a noop, see a81b000a39
Merged-by: Clément Bœsch <u@pkh.me>
* commit '12004a9a7f20e44f4da2ee6c372d5e1794c8d6c5':
audiodsp/x86: yasmify vector_clipf_sse
audiodsp: reorder arguments for vector_clipf
Merged the version from Libav after a discussion with James Almer on
IRC:
19:22 <ubitux> jamrial: opinion on 12004a9a7f20e44f4da2ee6c372d5e1794c8d6c5?
19:23 <ubitux> it was apparently yasmified differently
19:23 <ubitux> (it depends on the previous commit arg shuffle)
19:24 <ubitux> i don't see the magic movsxdifnidn in your port btw
19:24 <ubitux> it's a port from 1d36defe94
19:25 <jamrial> seems better thanks to said arg shuffle
19:25 <jamrial> the loop is the same, but init is simpler
19:25 <jamrial> probably worth merging
19:25 <ubitux> OK
19:25 <ubitux> thanks
19:26 <jamrial> curious they didn't make len ptrdiff_t after the previous bunch of commits, heh
19:26 <ubitux> yeah indeed
Both commits are merged at the same time to prevent a conflict with our
existing yasmified ff_vector_clipf_sse.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'eea9857bfd6925d0c34382c00b971ee6df12ad44':
blockdsp: drop the high_bit_depth parameter
This commit is a noop, see 562ba4a827
Merged-by: Clément Bœsch <u@pkh.me>
* commit '340f12f71207513672b5165d810cb6c8622c6b21':
hwcontext_cuda: Add P010 and YUV444P16 pixel format
This commit is a noop, we already have P010 and P016.
18:52 <@BtbN> Adding AV_PIX_FMT_YUV444P16 won't hurt, but doesn't gain anything.
18:53 <@BtbN> I'd say just noop it. If we'll ever need it, it will be added in turn.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '75d98e30afab61542faab3c0f11880834653bd6b':
audiodsp/x86: clear the high bits of the order parameter on 64bit
Merged-by: Clément Bœsch <u@pkh.me>
* commit '1d6c76e11febb58738c9647c47079d02b5e10094':
audiodsp/x86: fix ff_vector_clip_int32_sse2
No functionnal changes, only cosmetics. This issue was fixed in
9a9e2f1c8a.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'de64dd13cbd47fd54334b6aa2a2cd3c7c36daae2':
avcodec: Add the extended pixel format profile for HEVC
This commit is a noop, see 5a41999d81
Merged-by: Clément Bœsch <u@pkh.me>
* commit '136f55207521f0b03194ef5b55ba70f1635d6aee':
mpegvideo_motion: Handle edge emulation even without unrestricted_mv
This commit is a noop, see 7b1e0beb2d
Merged-by: Clément Bœsch <u@pkh.me>
* commit '15fcf6292ed79be274c824fedb099c2665f4cc15':
build: remove hardcoded name of version header
This commit is noop, our version.sh is completely different.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '8c201dde0ab62e5cd581d958e78d7609e0ba710d':
build: doc: more fine-grained dependencies for generated texi files
This commit is a noop, we have a different system for handling the
documentation.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'bc7399934def210c2a84ea51375d50f79c676c96':
libdc1394: Distinguish between enumeration errors and no cameras found
This commit is a noop, see 384251daff
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'df3795025337479a639cb3cd26c93a4e82ccd4db':
rtsp: Fix a crash with the RTSP muxer
This commit is a noop, see f8a13c7213
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3a9662af6c741f8354b1ca97642f78f5c02e2e8f':
vaapi_h264: Fix HRD bit_rate/cpb_size scaling
This commit is a noop, see 06d73d002e
Merged-by: Clément Bœsch <u@pkh.me>
* commit '7081620aca36e616ea96f71fd71d2703e3abae09':
hwcontext_vdpau: Fix missing subscripts
This commit is a noop, see f7e9275f83
Merged-by: Clément Bœsch <u@pkh.me>
Regression from 4563a86f01.
Both need stdint.h included before the respective x264.h and xavs.h.
Old require() used different, separate checks that didn't actually
need stdint.h to work. require2()'s (now require) check_func_headers()
does include stdint.h but only after the custom headers.
For libxavs this would also be consequently fixed by libav's
commit 20abcaa273 which wasn't merged yet.
* commit 'ab3554e1a7c04a5ea30f9c905de92348478ef7c8':
configure: Drop check_lib()/require() in favor of check_lib2()/require2()
Merged-by: Clément Bœsch <u@pkh.me>
* commit '6ce93757ee6b81fe727bfdc9f546fd0ddf9139c3':
ppc: Update #endif comments
This commit is mostly a noop as we seem to support PPC LE (see
902ce2a6c4). Only the h264 chunks are
updated.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '75d642a944d5579e4ef20ff3701422a64692afcf':
vaapi_vp8: Explicitly include libva vp8 decode header
vaapi_decode: Ignore the profile when not useful
lavc/vaapi: Add VP8 decode hwaccel
vp8: Add hwaccel hooks
This merge is a noop as these commits are already under review on the
mailing list. doc/libav-merge.txt is updated to track its progress.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '52730e0f867fe77b7d2353d8b44e92edb7079ca5':
iir_filter: Change type of array stride parameters to ptrdiff_t
The merge also updates the MIPS code and drop the extra log.h include.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3aa9d37d03da3c9b482d19b3988659287815280e':
build: Fix directory dependencies of tests/pixfmts.mak target
This might not be necessary given our mkdirs in the configure, but it
probably doesn't hurt.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '0e5dde739943168d6f61d3fb40b3f622e7abfeff':
configure: Fix --disable-pod2man / --disable-texi2html
This commit is a noop, we have dedicated documentation option for this
purpose.
Merged-by: Clément Bœsch <u@pkh.me>
The configure has the --disable-manpages option for this purpose, and
--disable-pod2man is currently ignored due to that. This is also
consistent with the other documentation options.
* commit '2610c9528f86286e4c6e174411a26ff5b4815cde':
configure: Move initial VAAPI check to a more sensible place
This commit is a noop, see 17989dcf54
Merged-by: Clément Bœsch <u@pkh.me>
* commit '4fb311c804098d78e5ce5f527f9a9c37536d3a08':
Drop memalign hack
Merged, as this may indeed be uneeded since
46e3936fb0.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f01f7a7846529b7c3ef343f117eaa2c0a1457af0':
hwcontext_dxva2: use the special UC copy for downloading frames
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'd7bc52bf456deba0f32d9fe5c288ec441f1ebef5':
imgutils: add a function for copying image data from GPU mapped memory
Merged-by: Clément Bœsch <u@pkh.me>
* commit '851960f6f8cf1f946fe42fa36cf6598fac68072c':
lavc: Remove old vaapi decode infrastructure
avconv_vaapi: Convert to use hw_frames_ctx only
vaapi_mpeg4: Convert to use the new VAAPI hwaccel code
vaapi_vc1: Convert to use the new VAAPI hwaccel code
vaapi_mpeg2: Convert to use the new VAAPI hwaccel code
vaapi_h264: Convert to use the new VAAPI hwaccel code
lavc: Rewrite VAAPI decode infrastructure
This merge is a noop, these commits have already been cherry-picked.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '72eba6558ee4f10239ba3f472c0b033ec70082a7':
wmavoice: Simplify GetBitContext initialization
This commit is a noop. We don't have that code anymore since
3deb4b54a2.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '728e80cd2e1d4b7c3e26489efcd77bd7a9e84a99':
High Definition Compatible Digital (HDCD) decoder filter, using libhdcd
This commit is a noop, we have that code natively.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '95f80293456d9d4b1b096621260c38bc90325ec0':
avprobe: Fix memory leak
This commit is a noop, ffprobe is not affected.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '8db804e8f549d5b86a1edf62736e0ef80f160da9':
mov: Remove old b-frame/video delay heuristic
This commit is a noop, see 425be3c810
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'eb96505b761eb02b6a3efc76d854afa6a41941ff':
mov: Remove ancient heuristic hack
This commit is a noop, see 04f8d31287
Merged-by: Clément Bœsch <u@pkh.me>
Fixes: 864/clusterfuzz-testcase-4774385942528000
See: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_direct: Fix runtime error: signed integer overflow: 2147483647 - -14133 cannot be represented in type 'int'
See: [FFmpeg-devel] [PATCH 2/2] avcodec/h264_direct: Fix runtime error: signed integer overflow: -9 - 2147483647 cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This work is sponsored by, and copyright, Google.
This avoids loading and calculating coefficients that we know will
be zero, and avoids filling the temp buffer with zeros in places
where we know the second pass won't read.
This gives a pretty substantial speedup for the smaller subpartitions.
The code size increases from 21512 bytes to 31400 bytes.
The idct16/32_end macros are moved above the individual functions; the
instructions themselves are unchanged, but since new functions are added
at the same place where the code is moved from, the diff looks rather
messy.
Before:
vp9_inv_dct_dct_16x16_sub1_add_10_neon: 284.6
vp9_inv_dct_dct_16x16_sub2_add_10_neon: 1902.7
vp9_inv_dct_dct_16x16_sub4_add_10_neon: 1903.0
vp9_inv_dct_dct_16x16_sub8_add_10_neon: 2201.1
vp9_inv_dct_dct_16x16_sub12_add_10_neon: 2510.0
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 2821.3
vp9_inv_dct_dct_32x32_sub1_add_10_neon: 1011.6
vp9_inv_dct_dct_32x32_sub2_add_10_neon: 9716.5
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 9704.9
vp9_inv_dct_dct_32x32_sub8_add_10_neon: 10641.7
vp9_inv_dct_dct_32x32_sub12_add_10_neon: 11555.7
vp9_inv_dct_dct_32x32_sub16_add_10_neon: 12499.8
vp9_inv_dct_dct_32x32_sub20_add_10_neon: 13403.7
vp9_inv_dct_dct_32x32_sub24_add_10_neon: 14335.8
vp9_inv_dct_dct_32x32_sub28_add_10_neon: 15253.6
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 16179.5
After:
vp9_inv_dct_dct_16x16_sub1_add_10_neon: 282.8
vp9_inv_dct_dct_16x16_sub2_add_10_neon: 1142.4
vp9_inv_dct_dct_16x16_sub4_add_10_neon: 1139.0
vp9_inv_dct_dct_16x16_sub8_add_10_neon: 1772.9
vp9_inv_dct_dct_16x16_sub12_add_10_neon: 2515.2
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 2823.5
vp9_inv_dct_dct_32x32_sub1_add_10_neon: 1012.7
vp9_inv_dct_dct_32x32_sub2_add_10_neon: 6944.4
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 6944.2
vp9_inv_dct_dct_32x32_sub8_add_10_neon: 7609.8
vp9_inv_dct_dct_32x32_sub12_add_10_neon: 9953.4
vp9_inv_dct_dct_32x32_sub16_add_10_neon: 10770.1
vp9_inv_dct_dct_32x32_sub20_add_10_neon: 13418.8
vp9_inv_dct_dct_32x32_sub24_add_10_neon: 14330.7
vp9_inv_dct_dct_32x32_sub28_add_10_neon: 15257.1
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 16190.6
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This reduces the code size of libavcodec/aarch64/vp9itxfm_16bpp_neon.o from
26288 to 21512 bytes.
This gives a small slowdown of a couple of tens of cycles, but makes
it more feasible to add more optimized versions of these transforms.
Before:
vp9_inv_dct_dct_16x16_sub4_add_10_neon: 1887.4
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 2801.5
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 9691.4
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 16154.9
After:
vp9_inv_dct_dct_16x16_sub4_add_10_neon: 1899.5
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 2827.2
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 9714.7
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 16175.9
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This reduces the code size of libavcodec/arm/vp9itxfm_16bpp_neon.o from
17500 to 14516 bytes.
This gives a small slowdown of a couple tens of cycles, up to around
150 cycles for the full case of the largest transform, but makes
it more feasible to add more optimized versions of these transforms.
Before: Cortex A7 A8 A9 A53
vp9_inv_dct_dct_16x16_sub4_add_10_neon: 4237.4 3561.5 3971.8 2525.3
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 6371.9 5452.0 5779.3 3910.5
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 22068.8 17867.5 19555.2 13871.6
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 37268.9 38684.2 32314.2 23969.0
After:
vp9_inv_dct_dct_16x16_sub4_add_10_neon: 4375.1 3571.9 4283.8 2567.2
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 6415.6 5578.9 5844.6 3948.3
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 22653.7 18079.7 19603.7 13905.3
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 37593.2 38862.2 32235.8 24070.9
Signed-off-by: Martin Storsjö <martin@martin.st>
Keep the idct32 coefficients in narrow form in q6-q7, and idct16
coefficients in lengthened 32 bit form in q0-q3. Avoid clobbering
q0-q3 in the pass1 function, and squeeze the idct16 coefficients
into q0-q1 in the pass2 function to avoid reloading them.
The idct16 coefficients are clobbered and reloaded within idct32_odd
though, since that turns out to be faster than narrowing them and
swapping them into q6-q7.
Before: Cortex A7 A8 A9 A53
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 22653.8 18268.4 19598.0 14079.0
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 37699.0 38665.2 32542.3 24472.2
After:
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 22270.8 18159.3 19531.0 13865.0
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 37523.3 37731.6 32181.7 24071.2
Signed-off-by: Martin Storsjö <martin@martin.st>
Align the second/third operands as they usually are.
Due to the wildly varying sizes of the written out operands
in aarch64 assembly, the column alignment is usually not as clear
as in arm assembly.
This is cherrypicked from libav commit
7995ebfad1.
Signed-off-by: Martin Storsjö <martin@martin.st>
In the half/quarter cases where we don't use the min_eob array, defer
loading the pointer until we know it will be needed.
This is cherrypicked from libav commit
3a0d5e206d.
Signed-off-by: Martin Storsjö <martin@martin.st>
This reduces the number of lines and reduces the duplication.
Also simplify the eob check for the half case.
If we are in the half case, we know we at least will need to do the
first three slices, we only need to check eob for the fourth one,
so we can hardcode the value to check against instead of loading
from the min_eob array.
Since at most one slice can be skipped in the first pass, we can
unroll the loop for filling zeros completely, as it was done for
the quarter case before.
This allows skipping loading the min_eob pointer when using the
quarter/half cases.
This is cherrypicked from libav commit
98ee855ae0.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '4ab496261b12e20ef293b7adca4fcaef1a67c538':
libvpx: Cast a pointer to const to squelch a warning
This commit is a noop, see 09b3bbe605
Merged-by: James Almer <jamrial@gmail.com>
* commit '802727b538b484e3f9d1345bfcc4ab24cfea8898':
vp8: Update some assembly comments left unchanged in bd66f073fe
Merged-by: James Almer <jamrial@gmail.com>
* commit '6755eb5b212384e0599f7f2c5de42df49fff57de':
mss12: validate display dimensions
This commit is a noop, see ee9151b616
Merged-by: Clément Bœsch <u@pkh.me>
* commit '33f10546ec012ad4e1054b57317885cded7e953e':
vc1: check that slices have a positive height
This commit is a noop, see e985cfd18b
Merged-by: Clément Bœsch <u@pkh.me>
* commit '09b23786b3986502ee88d4907356979127169bdd':
pcx: use the bytestream2 API for reading from input
This commit is a noop, see 8cd1c0febe
Merged-by: Clément Bœsch <u@pkh.me>
* commit '221402c1c88b9d12130c6f5834029b535ee0e0c5':
pcx: check that the packet is large enough before reading the header
See 8cd1c0febe
Merged-by: Clément Bœsch <u@pkh.me>
* commit '15ee419b7abaf17f8c662c145fe93d3dbf43282b':
pcx: properly pad the scanline
This commit is a noop, see d24de4596c
Merged-by: Clément Bœsch <u@pkh.me>
* commit '796dca027be09334d7bbf4f2ac1200e06bb054cb':
alac: do not return success if nothing was decoded
See e11983bda0
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f5d46d332258dcd8ca623019ece1d5e5bb74142b':
vmnc: check that subrectangles fit into their containing rectangles
See 6ba02602aa
This merge keeps our condition against w-i and h-j instead of bw and bh.
One may be more correct than the other, but I'm keeping our behaviour
here for safety reasons.
The style and formatting is merged.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'b53d8c3ccfeff77874f5ca7c68136b6d87a0a69c':
mjpegdec: Drop disabled code
The last chunk is replaced with a comment describing the structure.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'aa37d2bf4505afc106e2a23c44afc722bb204a8e':
swscale: Kill non-compiling disabled cruft
The isGray() chunk is not merged as an alternative patch actually fixing
the dead code is currently under review on the mailing-list.
The SWS_X chunk is merged, with an additional cosmetic.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '00a0419c7f7ebce9010cba93b7ff67c9f1165815':
mathematics: Kill non-compiling disabled cruft
This commit is a noop, see 1e1513d01a
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5a667322f5cb0e77c15891fc06725c19d8f3314f':
vaapi_vc1: Remove redundant version check
This commit is a noop, see d07d01bcce
Merged-by: Clément Bœsch <u@pkh.me>
* commit '01d6f84f49a55fd591aa120960fce2b9dba92d0d':
vaapi_vc1: Constify pointers
This commit is a noop, see 845c2c140b
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'ee9061293e925916fe2e0b7c08fbbd1f981b1d29':
vaapi_mpeg2: Constify pointers
This commit is a noop, see 6bc2808c41
Merged-by: Clément Bœsch <u@pkh.me>
* commit '03adfe913062c6995136eb1ca51152b6d596c0f4':
vaapi_h264: Constify pointers
This commit is a noop, see d0897da924
Merged-by: Clément Bœsch <u@pkh.me>
* commit '121f34d5f0c8d7d376829a467590fbbe4c228f4f':
hwcontext_vaapi: Try the first render node as the default DRM device
This commit is a noop, see 8d47d84075
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f6d2fed811dea36c4ebaf991927e44c78eb0aca5':
avconv: Make sure that inputless filtergraphs are configured
This commit is a noop. Related code is pretty different in ffmpeg, and
-filter_complex testsrc works.
See also af1761f7b5
Merged-by: Clément Bœsch <u@pkh.me>
* commit '602abe77b02f9702c18c2787d208fcfc9d94b70f':
avconv: Check the fifo allocation
This commit is a noop, see af1761f7b5
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f2143c57b6a61fef382f3128138d8558a9bdecee':
vp9: reindent after last commit
vp9: add frame threading
vp9: allocate 'b', 'block/uvblock' and 'eob/uveob' dynamically.
vp9: split last/cur_frame from the reference buffers.
This commit is a noop, we already have all these changes. Again, we will
need in the future to analyse the tiny differences between the two
repository on the vp9 files. But in the current state, it's a real pain
to do at every commit due to the huge differences (such as files split
and cosmetics).
Merged-by: Clément Bœsch <u@pkh.me>
* commit '04763c6f87690b31cfcd0d324cf36a451531dcd0':
h264_direct: use the reference mask from the actual reference
This commit is a noop, see d8151a7e94
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e9bfff1cc66c85b91b262c41e8aa5e8685606225':
lavc: free buffer_frame/pkt on avcodec_open2() failure
This commit is a noop, see 27adf9f9cd.
Only reordered to reduce diff.
Merged-by: Clément Bœsch <u@pkh.me>
The typeof keyword is apparently not available when using the -std=c99 option.
Fixes the use of C11 atomic functions with old GCC.
Reviewed-by: Muhammad Faiz <mfcc64@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Not used by anything at all since we don't auto insert lavr filters.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
use fltp when doing s32 -> s32 resampling
because s32p has no simd optimization
benchmark:
old 17.913s
new 7.584s (use fma3)
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
These values are defined to be 32bit in the specification,
so it makes more sense to store them as fixed width.
Based on a patch by Micahel Niedermayer <michael@niedermayer.cc>.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This field is of little value, and interferes with testing side data,
since sizes can be different on multiple architectures.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit '0638b99cdba52554691fc668d9e477bc184c7a33':
aiff: Skip padding byte for odd-sized chunks
Also removes to odd-size checks from get_aiff_header and get_meta to use
the generic path introduced by the original commit.
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
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>
when set_compensation is called with zero sample_delta,
compensation does not happen (because dst_incr == ideal_dst_incr)
but compensation_distance is set
regression since 01ebb57c03
Found-by: wm4 <nfxjfg@googlemail.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
Reflects the actual code and silences a gcc warning:
ffprobe.c:1797:42: warning: passing argument 1 of 'av_spherical_tile_bounds' discards 'const' qualifier from pointer target type
* commit '0df4801105d84883071b0978cb3afc7cd5184ce8':
vp9: make mv bounds 32bit.
This commit is a noop, see 024fac5cd4
Merged-by: Clément Bœsch <u@pkh.me>
* commit '24a362569bff1d4161742fffaca80a4a4428be8a':
buffer: fix av_buffer_realloc() when the data is offset wrt buffer start
Merged-by: Clément Bœsch <u@pkh.me>
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]
* commit 'e99ecda55082cb9dde8fd349361e169dc383943a':
checkasm: add vp9 MC tests.
vp9mc/x86: sse2 MC assembly.
vp9mc/x86: add AVX and AVX2 MC
vp9mc/x86: rename ff_* to ff_vp9_*
vp9mc/x86: rename ff_avg[48]_sse to ff_avg[48]_mmxext
vp9mc/x86: simplify a few inits.
vp9mc/x86: add 16px functions (64bit only).
Noop (aside from a formatting comment in vp9mc.asm). We already have all
of this. We should consider making a final diff between the two projects
when the dust comes down.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '89466de4aeaf5e359489b81b8a9920a2bc7936d6':
vp9/x86: rename vp9dsp to vp9mc
File was already renamed, only the top description is updated.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '63ac8e2d93080b74f6be32c7c3c1a1e44aacf34e':
lavu: add LOCAL_ALIGNED_32
This commit is a noop, see 25d5ea6d5a
Merged-by: James Almer <jamrial@gmail.com>
* commit 'd3e4d406b020b0464486318aceda08bd8f69ca41':
h264dec: reset nb_slice_ctx_queued for hwaccel decoding
This commit is a noop, see 7448019890
Merged-by: James Almer <jamrial@gmail.com>
* commit 'e5b019725f53b79159931d3a7317107cbbfd0860':
m4vdec: Check for non-startcode 00 00 00 sequences in probe
This commit is a noop, see 7c1835c52a
Merged-by: James Almer <jamrial@gmail.com>
* commit '3ccec334b8502701e72ef13bed25913c3578022e':
sbrdsp: Move a misplaced #endif directive to the right spot
Merged-by: James Almer <jamrial@gmail.com>
* commit 'e723dce6f8ba1e8260433b6ecfe5a3262f4c7a99':
dvbsubdec: Use NULL instead of 0 as pointer value
This commit is a noop. The affected code isn't in our tree.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'fc94a1acc27ab7296edce3fa81ef36691af5c134':
Revert "libavutil: Use an intermediate variable in AV_COPY*U"
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit '9806b9ab5c7fb2ac5efd8ffa8713fea0c5fd218d':
Revert "Don't use expressions with side effects in macro parameters"
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f79d847400d218cfd0b95f10358fe6e65ec3c9c4':
intreadwrite: Use the __unaligned keyword on MSVC for ARM and x86_64
Merged-by: James Almer <jamrial@gmail.com>
* commit '230b1c070baa3b6d4bd590426a365b843d60ff50':
intreadwrite: Add intermediate variables in the byteswise AV_W*() macros
Mostly a noop. Merged for cosmetic purposes.
See d83ff76ca0
Merged-by: James Almer <jamrial@gmail.com>
* commit '014773b66bdff4de24f384066d1a85d2a5bb6774':
libavutil: Use an intermediate variable in AV_COPY*U
This commit is a noop. It would be reverted in a future merge either
way.
Merged-by: James Almer <jamrial@gmail.com>
* commit '25bacd0a0c32ae682e6f411b1ac9020aeaabca72':
Don't use expressions with side effects in macro parameters
This commit is a noop. It would be reverted in a future merge either
way.
Merged-by: James Almer <jamrial@gmail.com>
Benchmarks with START_TIMER indicate that the code is faster with unsigned, (that is
with the patch), there was quite some fluctuation in the numbers so this may be just
random
Fixes: 811/clusterfuzz-testcase-6465493076541440
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
libnpp was erroneously grouped up with libfdk-aac and openssl to check
if --enable-nonfree wasn't passed only with --enable-gpl in
9f28db47ac. The latter two are compatible
with LGPL, libnpp is not.
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '7ebdffc353f3f0827864e8e3461fdc00cc243b14':
dxv: Check to make sure we don't overrun buffers on corrupt inputs
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e328178da90f44690e0076f4dbfd16da9175f441':
qsvdec: only access hwaccel_context is the pixel format is QSV
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5ebef79abecc3ffcc4ab0d46e203d13b068107c9':
Fix instances of broken indentation found by gcc 6
Noop, see 21d3f0c02, 6089c44a2
Merged-by: Clément Bœsch <u@pkh.me>
* commit '2ac00d2d1d51047c6ce69d5fbe1a08392d142658':
mov: Validate the ID number
This commit is a noop as the modified check is not present in FFmpeg.
See d30870cc73.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'a115eb9e750543f1d8bf951414d291069bf396c2':
mimic: do not release the newly obsolete reference at the end of decoding
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'ae90119c6701fa09ff747cca35238e36b2d2ab2f':
configure: Simplify license incompatibility check
An extra GPLV3 list is added for libsmbclient as having it in both GPL
and VERSION3 lists would cause a duplicate in the final config list.
Also, for consistency, libnpp is treated the same as the other nonfree
component (libfdk_aac and openssl).
Merged-by: Clément Bœsch <u@pkh.me>
add kVTCompressionPropertyKey_DataRateLimits support by rc_max_bitrate
Reviewed-by: Rick Kern <kernrj@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
* commit 'e46a6fb7732a7caef97a916a4f765ec0f779d195':
avconv: Check that muxing_queue exists before reading from it
Mostly noop. This was fixed in FFmpeg in 7f7c494a3.
The merge makes the cosmetics match but does not include the weird
av_log().
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '100fb0ddfda958da70f98feac81f924c02483789':
configure: Allow detecting and using LLVM lld-link as linker for windows
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '56af0bc10f49654b5b5f3efe82c69a13bf15fc8b':
configure: Check for strtoll and redirect to _strtoi64 in the msvcrt block
Also includes _strtoui64 in the check.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'b183abfb5b6366b177cf44f244c66156257a6fd6':
vpx: Support color range
Decoder chunk not merged as the framework automatically copies avctx
color range to the frame color range. And we already set the avctx field
since cbcc88c039.
Merged-by: Clément Bœsch <cboesch@gopro.com>
Preparation for potentially disabling merged side data by default in the
libs. Do this in particular because it affects fate tests.
The changed tests either reflect added packet side data, or the changed
packet size due to merged side data removal reducing the packet size.
The current form of the messages indicating matches in the white
or black lists seems to be a bit too much relying on context.
Make the messages more explicit.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Fixes: 755/clusterfuzz-testcase-5369072516595712
See: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_direct: Fix runtime error: signed integer overflow: 2147483647 - -14133 cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
the SECOND_LEVEL* flags process and name is too long
extract all of them output to funtions, make code clear
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
so tsf option in aresample will have effect
previously tsf/internal_sample_format had no effect
fate is updated
s32p previously used fltp internally
dblp previously used fltp/dblp internally
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
Add missing return value checks to suppress build warning and
remove noop ff_formats_unref() calling.
Note: most filters using ff_formats_ref() didn't have a suitable
error handling, it's a potential memory leak issue.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
* commit 'ad71d3276fef0ee7e791e62bbfe9c4e540047417':
lavfi: add a QSV deinterlacing filter
Minor fixup for lavfi differences.
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit '0956fd460681e8ccbdae19f135f0d3970bf95c2f':
qsvenc: do not re-execute encoding on all positive status codes
Noop, see fb240a6276.
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit 'd9ec3c60143babe1bb77c268e1d5547d15acd69b':
qsvenc: take only the allocated dimensions from the frames context
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit '8b7a9729aa162e2bbd571933f1aa40767f1ff47b':
avconv_qsv: use the actual pixel format provided by lavc
This commit is a noop, see 03cef34aa6
Merged-by: Clément Bœsch <u@pkh.me>
* commit '6f40181cad8ac04adff7bd10e1e1ab65f22bc1f0':
avconv_qsv: align the surface size to 32
This commit is a noop, see 03cef34aa6
Merged-by: Clément Bœsch <u@pkh.me>
Fixes: 732/clusterfuzz-testcase-4872990070145024
See: [FFmpeg-devel] [PATCH 2/6] avcodec/dca_xll: Fix runtime error: signed integer overflow: 2147286116 + 6298923 cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Provides a way to change bandwidth parameter inside DASH manifest after a non-CBR H.264 encoding.
Caller now is able to compute the bitrate by itself, after all packets have been written, and then set that value in AVFormatContext->streams->codecpar->bit_rate before calling av_write_trailer. As a result that value will be set in DASH manifest.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This matches the order they are in the 16 bpp version.
There they are in this order, to make sure we access them in the
same order they are declared, easing loading only half of the
coefficients at a time.
This makes the 8 bpp version match the 16 bpp version better.
This is cherrypicked from libav commit
b8f66c0838.
Signed-off-by: Martin Storsjö <martin@martin.st>
This matches the order they are in the 16 bpp version.
There they are in this order, to make sure we access them in the
same order they are declared, easing loading only half of the
coefficients at a time.
This makes the 8 bpp version match the 16 bpp version better.
This is cherrypicked from libav commit
08074c092d.
Signed-off-by: Martin Storsjö <martin@martin.st>
All elements are used pairwise, except for the first one.
Previously, the 16th element was unused. Move the unused element
to the second slot, to make the later element pairs not split
across registers.
This simplifies loading only parts of the coefficients,
reducing the difference to the 16 bpp version.
This is cherrypicked from libav commit
09eb88a12e.
Signed-off-by: Martin Storsjö <martin@martin.st>
All elements are used pairwise, except for the first one.
Previously, the 16th element was unused. Move the unused element
to the second slot, to make the later element pairs not split
across registers.
This simplifies loading only parts of the coefficients,
reducing the difference to the 16 bpp version.
This is cherrypicked from libav commit
de06bdfe6c.
Signed-off-by: Martin Storsjö <martin@martin.st>
The idct32x32 function actually pushed d8-d15 onto the stack even
though it didn't clobber them; there are plenty of registers that
can be used to allow keeping all the idct coefficients in registers
without having to reload different subsets of them at different
stages in the transform.
After this, we still can skip pushing d12-d15.
Before:
vp9_inv_dct_dct_32x32_sub32_add_neon: 8128.3
After:
vp9_inv_dct_dct_32x32_sub32_add_neon: 8053.3
This is cherrypicked from libav commit
65aa002d54.
Signed-off-by: Martin Storsjö <martin@martin.st>
The idct32x32 function actually pushed q4-q7 onto the stack even
though it didn't clobber them; there are plenty of registers that
can be used to allow keeping all the idct coefficients in registers
without having to reload different subsets of them at different
stages in the transform.
Since the idct16 core transform avoids clobbering q4-q7 (but clobbers
q2-q3 instead, to avoid needing to back up and restore q4-q7 at all
in the idct16 function), and the lanewise vmul needs a register in
the q0-q3 range, we move the stored coefficients from q2-q3 into q4-q5
while doing idct16.
While keeping these coefficients in registers, we still can skip pushing
q7.
Before: Cortex A7 A8 A9 A53
vp9_inv_dct_dct_32x32_sub32_add_neon: 18553.8 17182.7 14303.3 12089.7
After:
vp9_inv_dct_dct_32x32_sub32_add_neon: 18470.3 16717.7 14173.6 11860.8
This is cherrypicked from libav commit
402546a172.
Signed-off-by: Martin Storsjö <martin@martin.st>
For this case, with 8 inputs but only changing 4 of them, we can fit
all 16 input pixels into a q register, and still have enough temporary
registers for doing the loop filter.
The wd=8 filters would require too many temporary registers for
processing all 16 pixels at once though.
Before: Cortex A7 A8 A9 A53
vp9_loop_filter_mix2_v_44_16_neon: 289.7 256.2 237.5 181.2
After:
vp9_loop_filter_mix2_v_44_16_neon: 221.2 150.5 177.7 138.0
This is cherrypicked from libav commit
575e31e931.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is one cycle faster in total, and three instructions fewer.
Before:
vp9_loop_filter_mix2_v_44_16_neon: 123.2
After:
vp9_loop_filter_mix2_v_44_16_neon: 122.2
This is cherrypicked from libav commit
3bf9c48320.
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes building with clang for linux with PIC enabled.
This is cherrypicked from libav commit
8847eeaa14.
Signed-off-by: Martin Storsjö <martin@martin.st>
This adds lots of extra .ifs, but speeds it up by a couple cycles,
by avoiding stalls.
This is cherrypicked from libav commit
b0806088d3.
Signed-off-by: Martin Storsjö <martin@martin.st>
This adds lots of extra .ifs, but speeds it up by a couple cycles,
by avoiding stalls.
This is cherrypicked from libav commit
e18c39005a.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously we first calculated hev, and then negated it.
Since we were able to schedule the negation in the middle
of another calculation, we don't see any gain in all cases.
Before: Cortex A7 A8 A9 A53 A53/AArch64
vp9_loop_filter_v_4_8_neon: 147.0 129.0 115.8 89.0 88.7
vp9_loop_filter_v_8_8_neon: 242.0 198.5 174.7 140.0 136.7
vp9_loop_filter_v_16_8_neon: 500.0 419.5 382.7 293.0 275.7
vp9_loop_filter_v_16_16_neon: 971.2 825.5 731.5 579.0 453.0
After:
vp9_loop_filter_v_4_8_neon: 143.0 127.7 114.8 88.0 87.7
vp9_loop_filter_v_8_8_neon: 241.0 197.2 173.7 140.0 136.7
vp9_loop_filter_v_16_8_neon: 497.0 419.5 379.7 293.0 275.7
vp9_loop_filter_v_16_16_neon: 965.2 818.7 731.4 579.0 452.0
This is cherrypicked from libav commit
e1f9de86f4.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
Before: Cortex A53
vp9_inv_dct_dct_16x16_sub1_add_neon: 235.3
vp9_inv_dct_dct_32x32_sub1_add_neon: 555.1
After:
vp9_inv_dct_dct_16x16_sub1_add_neon: 180.2
vp9_inv_dct_dct_32x32_sub1_add_neon: 475.3
This is cherrypicked from libav commit
3fcf788fbb.
Signed-off-by: Martin Storsjö <martin@martin.st>
No measured speedup on a Cortex A53, but other cores might benefit.
This is cherrypicked from libav commit
388e0d2515.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fold the field lengths into the macro.
This makes the macro invocations much more readable, when the
lines are shorter.
This also makes it easier to use only half the registers within
the macro.
This is cherrypicked from libav commit
5e0c2158fb.
Signed-off-by: Martin Storsjö <martin@martin.st>
The ld1r is a leftover from the arm version, where this trick is
beneficial on some cores.
Use a single-lane load where we don't need the semantics of ld1r.
This is cherrypicked from libav commit
ed8d293306.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This avoids loading and calculating coefficients that we know will
be zero, and avoids filling the temp buffer with zeros in places
where we know the second pass won't read.
This gives a pretty substantial speedup for the smaller subpartitions.
The code size increases from 14740 bytes to 24292 bytes.
The idct16/32_end macros are moved above the individual functions; the
instructions themselves are unchanged, but since new functions are added
at the same place where the code is moved from, the diff looks rather
messy.
Before:
vp9_inv_dct_dct_16x16_sub1_add_neon: 236.7
vp9_inv_dct_dct_16x16_sub2_add_neon: 1051.0
vp9_inv_dct_dct_16x16_sub4_add_neon: 1051.0
vp9_inv_dct_dct_16x16_sub8_add_neon: 1051.0
vp9_inv_dct_dct_16x16_sub12_add_neon: 1387.4
vp9_inv_dct_dct_16x16_sub16_add_neon: 1387.6
vp9_inv_dct_dct_32x32_sub1_add_neon: 554.1
vp9_inv_dct_dct_32x32_sub2_add_neon: 5198.5
vp9_inv_dct_dct_32x32_sub4_add_neon: 5198.6
vp9_inv_dct_dct_32x32_sub8_add_neon: 5196.3
vp9_inv_dct_dct_32x32_sub12_add_neon: 6183.4
vp9_inv_dct_dct_32x32_sub16_add_neon: 6174.3
vp9_inv_dct_dct_32x32_sub20_add_neon: 7151.4
vp9_inv_dct_dct_32x32_sub24_add_neon: 7145.3
vp9_inv_dct_dct_32x32_sub28_add_neon: 8119.3
vp9_inv_dct_dct_32x32_sub32_add_neon: 8118.7
After:
vp9_inv_dct_dct_16x16_sub1_add_neon: 236.7
vp9_inv_dct_dct_16x16_sub2_add_neon: 640.8
vp9_inv_dct_dct_16x16_sub4_add_neon: 639.0
vp9_inv_dct_dct_16x16_sub8_add_neon: 842.0
vp9_inv_dct_dct_16x16_sub12_add_neon: 1388.3
vp9_inv_dct_dct_16x16_sub16_add_neon: 1389.3
vp9_inv_dct_dct_32x32_sub1_add_neon: 554.1
vp9_inv_dct_dct_32x32_sub2_add_neon: 3685.5
vp9_inv_dct_dct_32x32_sub4_add_neon: 3685.1
vp9_inv_dct_dct_32x32_sub8_add_neon: 3684.4
vp9_inv_dct_dct_32x32_sub12_add_neon: 5312.2
vp9_inv_dct_dct_32x32_sub16_add_neon: 5315.4
vp9_inv_dct_dct_32x32_sub20_add_neon: 7154.9
vp9_inv_dct_dct_32x32_sub24_add_neon: 7154.5
vp9_inv_dct_dct_32x32_sub28_add_neon: 8126.6
vp9_inv_dct_dct_32x32_sub32_add_neon: 8127.2
This is cherrypicked from libav commit
a63da4511d.
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows reusing the macro for a separate implementation of the
pass2 function.
This is cherrypicked from libav commit
79d332ebbd.
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows reusing the macro for a separate implementation of the
pass2 function.
This is cherrypicked from libav commit
47b3c2c18d.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This reduces the code size of libavcodec/aarch64/vp9itxfm_neon.o from
19496 to 14740 bytes.
This gives a small slowdown of a couple of tens of cycles, but makes
it more feasible to add more optimized versions of these transforms.
Before:
vp9_inv_dct_dct_16x16_sub4_add_neon: 1036.7
vp9_inv_dct_dct_16x16_sub16_add_neon: 1372.2
vp9_inv_dct_dct_32x32_sub4_add_neon: 5180.0
vp9_inv_dct_dct_32x32_sub32_add_neon: 8095.7
After:
vp9_inv_dct_dct_16x16_sub4_add_neon: 1051.0
vp9_inv_dct_dct_16x16_sub16_add_neon: 1390.1
vp9_inv_dct_dct_32x32_sub4_add_neon: 5199.9
vp9_inv_dct_dct_32x32_sub32_add_neon: 8125.8
This is cherrypicked from libav commit
115476018d.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This reduces the code size of libavcodec/arm/vp9itxfm_neon.o from
15324 to 12388 bytes.
This gives a small slowdown of a couple tens of cycles, up to around
150 cycles for the full case of the largest transform, but makes
it more feasible to add more optimized versions of these transforms.
Before: Cortex A7 A8 A9 A53
vp9_inv_dct_dct_16x16_sub4_add_neon: 2063.4 1516.0 1719.5 1245.1
vp9_inv_dct_dct_16x16_sub16_add_neon: 3279.3 2454.5 2525.2 1982.3
vp9_inv_dct_dct_32x32_sub4_add_neon: 10750.0 7955.4 8525.6 6754.2
vp9_inv_dct_dct_32x32_sub32_add_neon: 18574.0 17108.4 14216.7 12010.2
After:
vp9_inv_dct_dct_16x16_sub4_add_neon: 2060.8 1608.5 1735.7 1262.0
vp9_inv_dct_dct_16x16_sub16_add_neon: 3211.2 2443.5 2546.1 1999.5
vp9_inv_dct_dct_32x32_sub4_add_neon: 10682.0 8043.8 8581.3 6810.1
vp9_inv_dct_dct_32x32_sub32_add_neon: 18522.4 17277.4 14286.7 12087.9
This is cherrypicked from libav commit
0331c3f5e8.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids concatenation, which can't be used if the whole macro
is wrapped within another macro.
This is also arguably more readable.
This is cherrypicked from libav commit
58d87e0f49.
Signed-off-by: Martin Storsjö <martin@martin.st>
The 'sqrt' and 'cbrt' scalers were added in commit
80262d8c86, but their symbolic option values
only made available to the showwaves filter, not showwavespic, despite
the scalers working properly by their numerical option values.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
1. limit to single layer, as there is no current support for setting distortion/quality of multiple layers
2. encoder mode should be kept at default setting (0)
3. remove fixed_alloc parameter from context : seldom if ever used, and no way of properly configuring at the moment
4. add irreversible setting, to allow for lossless encoding. Set to OpenJPEG default (enabled)
5. set numresolution max to 33, which is the maximum number of allowed resolutions according the J2K spec
Signed-off-by: Michael Bradshaw <mjbshaw@google.com>
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 8a60bba0ae.
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 946ed78f5f (2012).
except filter_length == 1
odd filter_length gives worse frequency response,
even when compared with shorter filter_length
also makes build_filter simpler
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
This reverts commit faa9d29829.
This change became superfluous when support for C11 atomics was introduced.
Reverting it will make the removal of this implementation in an upcoming
merge conflict free.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The constants used in the decoder used floating point precision,
and this caused different values to be generated on different
architectures.
So, eradicate floating point numbers and use fixed point (32.32)
arithmetics everywhere, replacing constants with precomputed integer
values.
Signed-off-by: Vittorio Giovara <vittorio.giovara at gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The way videotoolbox hooks in as a hwaccel is pretty hacky. The VT decode
API is not invoked until end_frame(), so alloc_frame() returns a dummy
frame with a 1-byte buffer. When end_frame() is eventually called, the
dummy buffer is replaced with the actual decoded data from
VTDecompressionSessionDecodeFrame().
When the VT decoder fails, the frame returned to the h264 decoder from
alloc_frame() remains invalid and should not be used. Before
9747219958, it was accidentally being
returned all the way up to the API user. After that commit, the dummy
frame was unref'd so the user received an error.
However, since that commit, VT hwaccel failures started causing random
segfaults in the h264 decoder. This happened more often on iOS where the
VT implementation is more likely to throw errors on bitstream anomolies.
A recent report of this issue can be see in
http://ffmpeg.org/pipermail/libav-user/2016-November/009831.html
The issue here is that the dummy frame is still referenced internally by the
h264 decoder, as part of the reflist and cur_pic_ptr. Deallocating the
frame causes assertions like this one to trip later on during decoding:
Assertion h->cur_pic_ptr->f->buf[0] failed at src/libavcodec/h264_slice.c:1340
With this commit, we leave the dummy 1-byte frame intact, but avoid returning it
to the user.
This reverts commit 9747219958.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Without this the FPU state becomes trashed and causes mysterious
fate failures with cpuflags=0
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Ever since the codecpar changes, this has been always printed when
opening a flv file. This is because the codecpar changes made all
streams to be added lazily as read_packet is called.
There is no reason that draining couldn't return an error or two. But
some decoders don't handle this very well, and might always return an
error. This can lead to API users getting into an infinite loop and
burning CPU, because no progress is made and EOF is never returned.
In fact, ffmpeg.c contains a hack against such a case. It is made
unnecessary with this commit, and removed with the next one. (This
particular error case seems to have been fixed since the hack was
added, though.)
This might lose frames if decoding returns errors during draining.
The code modifying the buffer on big endian systems was removed.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
The filter field is often used to check whether a filter is
configured. If configuring the filter actually fails somewhere in
the middle of it, these fields could still be set to non-NULL, which
lead to other code accessing the half-configured filter graph, which
in turn could lead to crashes within libavfilter.
Solve this by properly resetting all fields.
This was triggered by a fuzzed sample after the recent changes. It's
unknown whether this behavior could be triggered before that.
If a subtitle packet came before the first video frame could be fully
decoded, the subtitle packet would get discarded. This puts the subtitle
into a queue instead, and processes it once the attached filter graph is
initialized.
Be more careful when an input stream encounters EOF when its filtergraph
has not been configured yet. The current code would immediately mark the
corresponding output streams as finished, while there may still be
buffered frames waiting for frames to appear on other filtergraph
inputs.
This should fix the random FATE failures for complex filtergraph tests
after a3a0230a98
This merges Libav commit 94ebf55. It was previously skipped.
This is the last filter init related Libav commit that was skipped, so
this also removes the commits from doc/libav-merge.txt.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
This is a more appropriate place for it, and will also be useful in the
following commit.
This merges Libav commit d2e56cf. It was previously skipped.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
This makes sure the actual stream parameters are used, which is
important mainly for hardware decoding+filtering cases, which would
previously require various weird workarounds to handle the fact that a
fake software graph has to be constructed, but never used.
This should also improve behaviour in rare cases where
avformat_find_stream_info() does not provide accurate information.
This merges Libav commit a3a0230. It was previously skipped.
The code in flush_encoders() which sets up a "fake" format wasn't in
Libav. I'm not sure if it's a good idea, but it tends to give
behavior closer to the old one in certain corner cases.
The vp8-size-change gives different result, because now the size of
the first frame is used. libavformat reported the size of the largest
frame for some reason.
The exr tests now use the sample aspect ratio of the first frame. For
some reason libavformat determines 0/1 as aspect ratio, while the
decoder returns the correct one.
The ffm and mxf tests change the field_order values. I'm assuming
another libavformat/decoding mismatch.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
This will be useful in the following commit, after which the muxer
timebase is not always available when encoding.
This merges Libav commit 3e265ca. It was previously skipped.
There are some changes with how/when the mux_timebase field is set,
because the Libav approach often causes a too imprecise time base
to be set. This is hard, because the muxer's write_header function
can readjust the timebase, at which point we might already have
encoded packets buffered. (It might be better to buffer them after
the encoder, instead of after all the timestamp handling logic
before muxing.)
The two FATE tests change because the output time base is raised
for subtitles. (Needed to avoid certain rounding issues in other
cases.)
Includes a minor merge fix by Mark Thompson, and
avconv: Move rescale to stream timebase before monotonisation
also by Mark Thompson <sw@jkqxz.net>.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Some callers (like do_subtitle_out()) call this with an AVPacket that is
not refcounted. This can cause undefined behavior.
Calling av_packet_move_ref() does not make a packet refcounted if it
isn't yet. (And it can't be made to, because it always succeeds,
and can't return ENOMEM.)
Call av_packet_ref() instead to make sure it's refcounted.
I couldn't find a case that is fixed by this with the current code. But
it will fix the fate-pva-demux test with the later patches applied.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Found a case where we use size==0, the other related commits
remain needed, and should be sufficient to fix the original issue
This reverts commit 7e4f32f4e4.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If AVVideotoolboxContext.cv_pix_fmt_type is set to 0, don't set the
kCVPixelBufferPixelFormatTypeKey value on the VT decoder.
This makes VT output its native format, which can be much faster on
some hardware iterations (if the native format does not match with
the requested format, it will be converted, which is slow).
The default is still forcing nv12.
Public fields were added after the private fields (negating the entire
point of this). New private fields go into AVStreamInternal anyway.
The new marker was set by guessing which fields are supposed to be
private and wshich not. recommended_encoder_configuration is accessed by
ffserver_config.c directly, and is supposed to use the public API.
ffmpeg.c accesses AVStream.cur_dts, even though it's a private field,
but that seems to be an older error.
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.
qmin and qmax are not necessary for nvenc vbr.
Enforcing this constraint, doesn't allow user to use vbr 2 pass mode without explicity setting the qmin and qmax options
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Leaving those variables in an undefined state allows them getting implicitly
enabled when they are declared as weak dependencies of other components.
In that case, the library check is not run and required linker flags are not
added, resulting in a failing build.
Fixes linking when enabling libfreetype without libfontconfig.
The map is a sparse array and does not need a empty element to terminate
it.
The empty element is stored after the last one inserted in the list,
overwriting whichever element was next with zeros.
Bug-Id: 1029
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Rodger Combs will be added to the ffmpeg-security alias when this patch is applied
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
wm4 will be added to the ffmpeg-security alias when this patch is applied
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The size 0 special case causes side data to be created which is
different and a special case if for any reasons size = 0 is passed
Fixes: multiple runtime error: null pointer passed as argument 1, which is declared to never be null
Fixes: 653/clusterfuzz-testcase-5773837415219200
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: shift exponent 34 is too large for 32-bit type 'int'
Fixes: 653/clusterfuzz-testcase-5773837415219200
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This should fix the fate failure due to a truncated last frame.
Alternatively the frame could be dropped.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The size field in the header/footer accounts for the entire APE tag
structure except the 32 bytes from header, for compatibility with
APEv1.
Signed-off-by: James Almer <jamrial@gmail.com>
CC: libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Currently it incorrectly compares bits with bytes.
Also, move the check right before where it's relevant, so that the
correct number of remaining bits is used.
CC: libav-stable@libav.org
According to the spec[1], a value of 0 means the footer is present and a value
of 1 means it's absent, the exact opposite of header presence flag where 1
means present and 0 absent.
The reason for this is compatibility with APEv1 tags, where there's no header,
footer presence was mandatory for all files, and the flags field was a zeroed
reserved field.
[1] http://wiki.hydrogenaud.io/index.php?title=Ape_Tags_Flags
Signed-off-by: James Almer <jamrial@gmail.com>
CC: libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>
MSVC doesn't support the %s time format, and instead of returning an
error the invalid parameter handler is invoked which (by default)
terminates the process.
Reviewed-by:Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>
refer to ticket id: #6170
rename file from temp to origin name after complete current segment
Reviewed-by: Aman Gupta <ffmpeg@tmm1.net>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Since the PVQ search has been well fuzzed and is guaranteed to never
break SUM(abs(y[])) == K, the assert is no longer needed.
Also the assert only prevented coding the wrong vector index but didn't
prevent crashes during searching for it, which made the assert rather
informational than practical.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Since the probelm mentioned only happened when the phase was negative
(e.g. the sum had to be decreased), only discarding dimensions with a
zero pulse in that case restored the search's previously low distortion
at low Ks when the phase is never negative.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This is not necessarily specific to fuzzed files
Fixes: Multiple integer overflows
Fixes: 656/clusterfuzz-testcase-6463814516080640
Fixes: 658/clusterfuzz-testcase-6691260146384896
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This matches the order they are in the 16 bpp version.
There they are in this order, to make sure we access them in the
same order they are declared, easing loading only half of the
coefficients at a time.
This makes the 8 bpp version match the 16 bpp version better.
Signed-off-by: Martin Storsjö <martin@martin.st>
This matches the order they are in the 16 bpp version.
There they are in this order, to make sure we access them in the
same order they are declared, easing loading only half of the
coefficients at a time.
This makes the 8 bpp version match the 16 bpp version better.
Signed-off-by: Martin Storsjö <martin@martin.st>
All elements are used pairwise, except for the first one.
Previously, the 16th element was unused. Move the unused element
to the second slot, to make the later element pairs not split
across registers.
This simplifies loading only parts of the coefficients,
reducing the difference to the 16 bpp version.
Signed-off-by: Martin Storsjö <martin@martin.st>
All elements are used pairwise, except for the first one.
Previously, the 16th element was unused. Move the unused element
to the second slot, to make the later element pairs not split
across registers.
This simplifies loading only parts of the coefficients,
reducing the difference to the 16 bpp version.
Signed-off-by: Martin Storsjö <martin@martin.st>
The idct32x32 function actually pushed d8-d15 onto the stack even
though it didn't clobber them; there are plenty of registers that
can be used to allow keeping all the idct coefficients in registers
without having to reload different subsets of them at different
stages in the transform.
After this, we still can skip pushing d12-d15.
Before:
vp9_inv_dct_dct_32x32_sub32_add_neon: 8128.3
After:
vp9_inv_dct_dct_32x32_sub32_add_neon: 8053.3
Signed-off-by: Martin Storsjö <martin@martin.st>
The idct32x32 function actually pushed q4-q7 onto the stack even
though it didn't clobber them; there are plenty of registers that
can be used to allow keeping all the idct coefficients in registers
without having to reload different subsets of them at different
stages in the transform.
Since the idct16 core transform avoids clobbering q4-q7 (but clobbers
q2-q3 instead, to avoid needing to back up and restore q4-q7 at all
in the idct16 function), and the lanewise vmul needs a register in
the q0-q3 range, we move the stored coefficients from q2-q3 into q4-q5
while doing idct16.
While keeping these coefficients in registers, we still can skip pushing
q7.
Before: Cortex A7 A8 A9 A53
vp9_inv_dct_dct_32x32_sub32_add_neon: 18553.8 17182.7 14303.3 12089.7
After:
vp9_inv_dct_dct_32x32_sub32_add_neon: 18470.3 16717.7 14173.6 11860.8
Signed-off-by: Martin Storsjö <martin@martin.st>
For this case, with 8 inputs but only changing 4 of them, we can fit
all 16 input pixels into a q register, and still have enough temporary
registers for doing the loop filter.
The wd=8 filters would require too many temporary registers for
processing all 16 pixels at once though.
Before: Cortex A7 A8 A9 A53
vp9_loop_filter_mix2_v_44_16_neon: 289.7 256.2 237.5 181.2
After:
vp9_loop_filter_mix2_v_44_16_neon: 221.2 150.5 177.7 138.0
Signed-off-by: Martin Storsjö <martin@martin.st>
This is one cycle faster in total, and three instructions fewer.
Before:
vp9_loop_filter_mix2_v_44_16_neon: 123.2
After:
vp9_loop_filter_mix2_v_44_16_neon: 122.2
Signed-off-by: Martin Storsjö <martin@martin.st>
libavcodec/vaapi.h:58:1: warning: attribute 'deprecated' is ignored, place it after "struct" to apply attribute to type declaration [-Wignored-attributes]
Fixes#6081. Some dictionary keys are not present on OS X 10.8.
This loads the symbols and uses a default value if not present.
Signed-off-by: Rick Kern <kernrj@gmail.com>
This ensures that the wrapped avframe will not get reallocated later, which
would invalidate internal references such as extended data.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
ts_offset was added to cluster timecode, but then effectively subtracted
back off the block timecode
When setting initial_padding for an audio stream, the timestamps are
written incorrectly to the mkv file. cluster timecode gets written
as pts0 + ts_offset which is correct, but then block timecode gets
written as pts - cluster timecode which expanded is
pts - (pts0 + ts_offset). Adding cluster and block tc back together:
cluster + block = (pts0 + ts_offset) + (pts - (pts0 + ts_offset)) = pts
But the result should be pts + ts_offset since demux will subtract the
CodecDelay element from pts and set initial_padding to CodecDelay.
This patch gives the correct result.
When setting the channel layout directly using AVBufferSrcParameters
the channel layout was correctly set however the init function still
expected the old string format to set the number of channels (when it
hadn't already been specified).
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The quantization table is stored in the natural order, but when we
access it, we use an index that's in zigzag order, causing us to read
the wrong value. This causes artifacts, especially in areas with
horizontal or vertical edges. The artifacts look a lot like the
DCT ringing artifacts you'd expect to see from a low-bitrate file,
but when comparing to NewTek's own decoder, it's obvious they're not
supposed to be there.
Fix by simply storing the scaled quantization table in zigzag order.
Performance is unchanged.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Have check_pkg_config() enable variables and set cflags and extralibs
instead of relegating that task to require_pkg_config. This simplifies
require_pkg_config(), is consistent with what other helper functions
like check_lib() do and allows getting rid of some manual variable
setting in places where check_pkg_config() is used.
If the PVQ search picked a place to increment/decrement on the y[]
vector which had no pulse then it would cause a desync since it would
change the sum in the wrong direction. Fix this by not considering
places without pulses as viable.
This makes the PVQ search slightly worse at K < 5 which isn't all that
common. Still, this is a workaround to prevent making broken files until
I can think of a better way of fixing it.
Also add an assertion, which can be removed or moved to assert1/2 once
the PVQ search is stable.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This dts value can end up in the list in the absence of durations and is in that
case semantically identical to AV_NOPTS_VALUE. We can alternatively prevent
storing RELATIVE_TS_BASE if there is no duration.
Fixes Ticket3640
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This was broken by 4e528206bc - the webp
decoder was assuming that it could set the output pixfmt of the vp8
decoder directly, but after that change it no longer could because
ff_get_format() was used instead. This adds an internal get_format()
callback to webp use of the vp8 decoder to override the pixfmt
appropriately.
Originally committed to x264 in 1637239a by Henrik Gramner who has
agreed to re-license it as LGPL. Original commit message follows.
x86: Avoid some bypass delays and false dependencies
A bypass delay of 1-3 clock cycles may occur on some CPUs when transitioning
between int and float domains, so try to avoid that if possible.
If there is progressive input it will disable deinterlacing in cuvid for
all future frames even those interlaced.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Fixes Ticket 6018
This fixes a regression, and allows playback of files containing mpeg4video that are otherwise
not supported
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When the http method is not set, the method will use POST for ts,
PUT for m3u8, it is not unify, now set it unify.
This ticket id: #5315
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
The Intel proprietary VAAPI driver enforces the restriction that a
buffer must be created inside an existing context, so just ensure
this is always true.
Channel mapping 2 additionally supports a non-diegetic stereo track
appended to the end of a full-order ambisonics signal, such that the
total channel count is either
(n + 1) ^ 2, or
(n + 1) ^ 2 + 2
where n is the ambisonics order
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When slice_h is rounded up due to chroma subsampling, there's
a risk that jobnr * slice_h exceeds frame->height.
Prior to a638e9184d, this wasn't an issue for the last slice
of a frame, since slice_end was set to frame->height for the last
slice.
a638e9184d tried to fix the case where other slices than the
last one would exceed frame->height (which can happen where the
number of slices/threads is very large compared to the frame
height).
However, the fix in a638e9184d instead broke other cases,
where slice_h * nb_threads < frame->height. Therefore, make
sure the last slice always ends at frame->height.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
If the stream timebase is coarser than the muxing timebase then the
monotonisation process may fail because adding one to the timestamp
need not actually produce a different timestamp after the rescale.
Some muxers may use the BMP_HEADER Format Data size instead
of the ASF-specific one.
Bug-Id: 1020
CC: libav-stable@libav.org
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Skips using temporary files when outputting to a protocol other than
"file", which enables dash to output content over network
protocols. The logic has been copied from the HLS format.
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit optimizes HTTP performance by reducing forward seeks, instead
favoring a read-ahead and discard on the current connection (referred to
as a short seek) for seeks that are within a TCP window's worth of data.
This improves performance because with TCP flow control, a window's worth
of data will be in the local socket buffer already or in-flight from the
sender once congestion control on the sender is fully utilizing the window.
Note: this approach doesn't attempt to differentiate from a newly opened
connection which may not be fully utilizing the window due to congestion
control vs one that is. The receiver can't get at this information, so we
assume worst case; that full window is in use (we did advertise it after all)
and that data could be in-flight
The previous behavior of closing the connection, then opening a new
with a new HTTP range value results in a massive amounts of discarded
and re-sent data when large TCP windows are used. This has been observed
on MacOS/iOS which starts with an initial window of 256KB and grows up to
1MB depending on the bandwidth-product delay.
When seeking within a window's worth of data and we close the connection,
then open a new one within the same window's worth of data, we discard
from the current offset till the end of the window. Then on the new
connection the server ends up re-sending the previous data from new
offset till the end of old window.
Example (assumes full window utilization):
TCP window size: 64KB
Position: 32KB
Forward seek position: 40KB
* (Next window)
32KB |--------------| 96KB |---------------| 160KB
*
40KB |---------------| 104KB
Re-sent amount: 96KB - 40KB = 56KB
For a real world test example, I have MP4 file of ~25MB, which ffplay
only reads ~16MB and performs 177 seeks. With current ffmpeg, this results
in 177 HTTP GETs and ~73MB worth of TCP data communication. With this
patch, ffmpeg issues 4 HTTP GETs and 3 seeks for a total of ~22MB of TCP data
communication.
To support this feature, the short seek logic in avio_seek() has been
extended to call a function to get the short seek threshold value. This
callback has been plumbed to the URLProtocol structure, which now has
infrastructure in HTTP and TCP to get the underlying receiver window size
via SO_RCVBUF. If the underlying URL and protocol don't support returning
a short seek threshold, the default s->short_seek_threshold is used
This feature has been tested on Windows 7 and MacOS/iOS. Windows support
is slightly complicated by the fact that when TCP window auto-tuning is
enabled, SO_RCVBUF doesn't report the real window size, but it does if
SO_RCVBUF was manually set (disabling auto-tuning). So we can only use
this optimization on Windows in the later case
Signed-off-by: Joel Cunningham <joel.cunningham@me.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This marks the first time anyone has written an Opus encoder without
using any libopus code. The aim of the encoder is to prove how far
the format can go by writing the craziest encoder for it.
Right now the encoder's basic, it only supports CBR encoding, however
internally every single feature the CELT layer has is implemented
(except the pitch pre-filter which needs to work well with the rest of
whatever gets implemented). Psychoacoustic and rate control systems are
under development.
The encoder takes in frames of 120 samples and depending on the value of
opus_delay the plan is to use the extra buffered frames as lookahead.
Right now the encoder will pick the nearest largest legal frame size and
won't use the lookahead, but that'll change once there's a
psychoacoustic system.
Even though its a pretty basic encoder its already outperforming
any other native encoder FFmpeg has by a huge amount.
The PVQ search algorithm is faster and more accurate than libopus's
algorithm so the encoder's performance is close to that of libopus
at zero complexity (libopus has more SIMD).
The algorithm might be ported to libopus or other codecs using PVQ in
the future.
The encoder still has a few minor bugs, like desyncs at ultra low
bitrates (below 9kbps with 20ms frames).
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This is meant to be applied on top of my previous patch which
split PVQ into celt_pvq.c and made opus_celt.h
Essentially nothing has been changed other than renaming CeltFrame
to CeltBlock (CeltFrame had absolutely nothing at all to do with
a frame) and CeltContext to CeltFrame.
3 variables have been put in CeltFrame as they make more sense
there rather than being passed around as arguments.
The coefficients have been moved to the CeltBlock structure
(why the hell were they in CeltContext and not in CeltFrame??).
Now the encoder would be able to use the exact context the decoder
uses (plus a couple of extra fields in there).
FATE passes, no slowdowns, etc.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
A huge amount can be reused by the encoder, as the only thing
which needs to be done would be to add a 10 line celt_icwrsi,
a wrapper around it (celt_alg_quant) and templating the
ff_celt_decode_band to replace entropy decoding functions
with entropy encoding.
There is no performance loss but in fact a performance gain of
around 6% which is caused by the compiler being able to optimize
the decoding more efficiently.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Handles strides (needed for Opus transients), does pre-reindexing and folding
without needing a copy.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Mostly used the RFC document, the decoding functions and
the reference encoder's implmenentation as a reference.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The driver is somewhat bitrotten (not updated for years) but is still
usable for decoding with this change. To support it, this adds a new
driver quirk to indicate no support at all for surface attributes.
Based on a patch by wm4 <nfxjfg@googlemail.com>.
A strict reading of the spec seems to imply that it should be aligned to
the start of the element instance tag, but that would break all of the
samples with PCEs.
It seems like a well formed LATM stream should have its PCE in the ASC
rather than inband.
Fixes ticket 4544
D3D9Ex uses different driver paths. This helps with "headless"
configurations when no user logs in. Plain D3D9 device creation will
fail if no user is logged in, while it works with D3D9Ex.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Merges Libav commit c2f97f0508.
This is an extended version of the AVFrame.opaque field, which can be
used to attach arbitrary user information to an AVFrame.
The usefulness of the opaque field is rather limited, because it can
store only up to 32 bits of information (or 64 bit on 64 bit systems).
It's not possible to set this field to a memory allocation, because
there is no way to deallocate it correctly.
The opaque_ref field circumvents this by letting the user set an
AVBuffer, which makes the user data refcounted.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Merges Libav commit 04f3bd3496.
hls-encoder currenlty does not provide stream level metadata to mpegts
muxer. This patch fixes track #3848 bug.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
This enables having multiple tracks of the same type which would
be treated as different things by the media server (as opposed to
different bit rate versions of the same track). According to the
smooth streaming specification, just setting the systemLanguage
tag is not enough to note that a track with the same attributes
differs from another one.
Reviewed-by: Martin
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The early check for inconsistent in-source vs out-of-source build
cannot generate a config.log otherwise.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
D3D9Ex uses different driver paths. This helps with "headless"
configurations when no user logs in. Plain D3D9 device creation will
fail if no user is logged in, while it works with D3D9Ex.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This is an extended version of the AVFrame.opaque field, which can be
used to attach arbitrary user information to an AVFrame.
The usefulness of the opaque field is rather limited, because it can
store only up to 32 bits of information (or 64 bit on 64 bit systems).
It's not possible to set this field to a memory allocation, because
there is no way to deallocate it correctly.
The opaque_ref field circumvents this by letting the user set an
AVBuffer, which makes the user data refcounted.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
When user use the hls_wrap, there have many problem:
1. some platform refersh the old but usefull segment
2. CDN(Content Delivery Network) Deliver HLS not friendly
The hls_wrap is used to wrap segments for use little space,
now user can use hls_list_size and hls_flags delete_segments
instead it.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Previously we first calculated hev, and then negated it.
Since we were able to schedule the negation in the middle
of another calculation, we don't see any gain in all cases.
Before: Cortex A7 A8 A9 A53 A53/AArch64
vp9_loop_filter_v_4_8_neon: 147.0 129.0 115.8 89.0 88.7
vp9_loop_filter_v_8_8_neon: 242.0 198.5 174.7 140.0 136.7
vp9_loop_filter_v_16_8_neon: 500.0 419.5 382.7 293.0 275.7
vp9_loop_filter_v_16_16_neon: 971.2 825.5 731.5 579.0 453.0
After:
vp9_loop_filter_v_4_8_neon: 143.0 127.7 114.8 88.0 87.7
vp9_loop_filter_v_8_8_neon: 241.0 197.2 173.7 140.0 136.7
vp9_loop_filter_v_16_8_neon: 497.0 419.5 379.7 293.0 275.7
vp9_loop_filter_v_16_16_neon: 965.2 818.7 731.4 579.0 452.0
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
Before: Cortex A53
vp9_inv_dct_dct_16x16_sub1_add_neon: 235.3
vp9_inv_dct_dct_32x32_sub1_add_neon: 555.1
After:
vp9_inv_dct_dct_16x16_sub1_add_neon: 180.2
vp9_inv_dct_dct_32x32_sub1_add_neon: 475.3
Signed-off-by: Martin Storsjö <martin@martin.st>
Fold the field lengths into the macro.
This makes the macro invocations much more readable, when the
lines are shorter.
This also makes it easier to use only half the registers within
the macro.
Signed-off-by: Martin Storsjö <martin@martin.st>
This way it's clear the size field accounts for the footer length plus every
tag entry, but not the header.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The size field in the header/footer accounts for the entire APE tag
structure except the 32 bytes from header, for compatibility with
APEv1.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
According to the spec[1], a value of 0 means the footer is present and a value
of 1 means it's absent, the exact opposite of header presence flag where 1
means present and 0 absent.
The reason for this is compatibility with APEv1 tags, where there's no header,
footer presence was mandatory for all files, and the flags field was a zeroed
reserved field.
[1] http://wiki.hydrogenaud.io/index.php?title=Ape_Tags_Flags
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This limits the bugs, speedloss and extra memory allocation to the case when
optimal tables are needed.
Fixes regressions with slice multi-threading
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If this is wanted iam not against it but it must be designed to work with all cases
like slice threads, and a single growing buffer does not work very well with slices.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The ld1r is a leftover from the arm version, where this trick is
beneficial on some cores.
Use a single-lane load where we don't need the semantics of ld1r.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This avoids loading and calculating coefficients that we know will
be zero, and avoids filling the temp buffer with zeros in places
where we know the second pass won't read.
This gives a pretty substantial speedup for the smaller subpartitions.
The code size increases from 14740 bytes to 24292 bytes.
The idct16/32_end macros are moved above the individual functions; the
instructions themselves are unchanged, but since new functions are added
at the same place where the code is moved from, the diff looks rather
messy.
Before:
vp9_inv_dct_dct_16x16_sub1_add_neon: 236.7
vp9_inv_dct_dct_16x16_sub2_add_neon: 1051.0
vp9_inv_dct_dct_16x16_sub4_add_neon: 1051.0
vp9_inv_dct_dct_16x16_sub8_add_neon: 1051.0
vp9_inv_dct_dct_16x16_sub12_add_neon: 1387.4
vp9_inv_dct_dct_16x16_sub16_add_neon: 1387.6
vp9_inv_dct_dct_32x32_sub1_add_neon: 554.1
vp9_inv_dct_dct_32x32_sub2_add_neon: 5198.5
vp9_inv_dct_dct_32x32_sub4_add_neon: 5198.6
vp9_inv_dct_dct_32x32_sub8_add_neon: 5196.3
vp9_inv_dct_dct_32x32_sub12_add_neon: 6183.4
vp9_inv_dct_dct_32x32_sub16_add_neon: 6174.3
vp9_inv_dct_dct_32x32_sub20_add_neon: 7151.4
vp9_inv_dct_dct_32x32_sub24_add_neon: 7145.3
vp9_inv_dct_dct_32x32_sub28_add_neon: 8119.3
vp9_inv_dct_dct_32x32_sub32_add_neon: 8118.7
After:
vp9_inv_dct_dct_16x16_sub1_add_neon: 236.7
vp9_inv_dct_dct_16x16_sub2_add_neon: 640.8
vp9_inv_dct_dct_16x16_sub4_add_neon: 639.0
vp9_inv_dct_dct_16x16_sub8_add_neon: 842.0
vp9_inv_dct_dct_16x16_sub12_add_neon: 1388.3
vp9_inv_dct_dct_16x16_sub16_add_neon: 1389.3
vp9_inv_dct_dct_32x32_sub1_add_neon: 554.1
vp9_inv_dct_dct_32x32_sub2_add_neon: 3685.5
vp9_inv_dct_dct_32x32_sub4_add_neon: 3685.1
vp9_inv_dct_dct_32x32_sub8_add_neon: 3684.4
vp9_inv_dct_dct_32x32_sub12_add_neon: 5312.2
vp9_inv_dct_dct_32x32_sub16_add_neon: 5315.4
vp9_inv_dct_dct_32x32_sub20_add_neon: 7154.9
vp9_inv_dct_dct_32x32_sub24_add_neon: 7154.5
vp9_inv_dct_dct_32x32_sub28_add_neon: 8126.6
vp9_inv_dct_dct_32x32_sub32_add_neon: 8127.2
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This reduces the code size of libavcodec/aarch64/vp9itxfm_neon.o from
19496 to 14740 bytes.
This gives a small slowdown of a couple of tens of cycles, but makes
it more feasible to add more optimized versions of these transforms.
Before:
vp9_inv_dct_dct_16x16_sub4_add_neon: 1036.7
vp9_inv_dct_dct_16x16_sub16_add_neon: 1372.2
vp9_inv_dct_dct_32x32_sub4_add_neon: 5180.0
vp9_inv_dct_dct_32x32_sub32_add_neon: 8095.7
After:
vp9_inv_dct_dct_16x16_sub4_add_neon: 1051.0
vp9_inv_dct_dct_16x16_sub16_add_neon: 1390.1
vp9_inv_dct_dct_32x32_sub4_add_neon: 5199.9
vp9_inv_dct_dct_32x32_sub32_add_neon: 8125.8
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This reduces the code size of libavcodec/arm/vp9itxfm_neon.o from
15324 to 12388 bytes.
This gives a small slowdown of a couple tens of cycles, up to around
150 cycles for the full case of the largest transform, but makes
it more feasible to add more optimized versions of these transforms.
Before: Cortex A7 A8 A9 A53
vp9_inv_dct_dct_16x16_sub4_add_neon: 2063.4 1516.0 1719.5 1245.1
vp9_inv_dct_dct_16x16_sub16_add_neon: 3279.3 2454.5 2525.2 1982.3
vp9_inv_dct_dct_32x32_sub4_add_neon: 10750.0 7955.4 8525.6 6754.2
vp9_inv_dct_dct_32x32_sub32_add_neon: 18574.0 17108.4 14216.7 12010.2
After:
vp9_inv_dct_dct_16x16_sub4_add_neon: 2060.8 1608.5 1735.7 1262.0
vp9_inv_dct_dct_16x16_sub16_add_neon: 3211.2 2443.5 2546.1 1999.5
vp9_inv_dct_dct_32x32_sub4_add_neon: 10682.0 8043.8 8581.3 6810.1
vp9_inv_dct_dct_32x32_sub32_add_neon: 18522.4 17277.4 14286.7 12087.9
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes all sorts of configuration problems introducec by dad7a9c7c0
on non-Linux or non-vanilla configs. Also removes a line made redundant
in that commit.
Only do this when building for a recent VAAPI version - initial
driver implementations were confused about the interpretation of the
framerate field, but hopefully this will be consistent everywhere
once 0.40.0 is released.
(cherry picked from commit ff35aa8ca4)
Default to using VBR when a target bitrate is set, unless the max rate
is also set and matches the target. Changes to the Intel driver mean
that min_qp is also respected in this case, so set a codec default to
unset the value rather than using the current default inherited from
the MPEG-4 part 2 encoder.
(cherry picked from commit eddfb57210)
This includes a backward-compatibility hack to choose CBR anyway on
old drivers which have no CBR support, so that existing programs will
continue to work their options now map to VBR.
(cherry picked from commit f033ba470f)
Before this change, it was possible to overflow pic_order_cnt_lsb and
generate a stream with invalid POC numbering. This makes sure that
the field is large enough that a single IDR B* P sequence uses fewer
than half the available POC lsb values.
(cherry picked from commit 89725a8512)
This change makes the configured GOP size be respected exactly -
previously the value could be exceeded slightly due to flaws in the
frame type selection logic.
(cherry picked from commit 37fab0661a)
This avoids having to count the number of frames sent to the codec
and the number of output packets received; instead just wait until
the encoder returns a buffer with the EOS flag set.
Signed-off-by: Martin Storsjö <martin@martin.st>
Core of patch is from paul@paulmehta.com
Reference https://crbug.com/643951
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Check value reduced as the code does not support values beyond INT_MAX
Also the check is moved to a more common place and before integer truncation
This allows distinguishing between the internal variable name for
external libraries and the pkg-config package name. Having both
names available avoids special-casing outside the helper function
when the two identifiers do not match.
Adds a `-hls_flags +temp_file` which will write segment data to
filename.tmp, and then rename to filename when the segment is complete.
This patch is similar in spirit to one used in Plex's ffmpeg fork, and
allows a transcoding webserver to ensure incomplete segment files are
never served up accidentally.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Bodecs Bela <bodecsb@vivanet.hu>
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Blocks are marked as key frames whenever the "reference" field is
zero. This breaks for non-keyframe Blocks with a reference timestamp
of zero.
The likelihood of reference timestamp being zero is increased by a
longstanding bug in muxing that encodes reference timestamp as the
absolute time of the referenced frame (rather than relative to the
current Block timestamp, as described in MKV spec).
Now using INT64_MIN to denote "no reference".
Reported to chromium at http://crbug.com/497889 (contains sample)
The original code is correctly following the API - vaTerminate() must
be called to free the resources of a VADisplay after it is created by
any of the vaGetDisplay*() calls; it is not necessary to have
successfully called vaInitialize() on it. The segfaults which
prompted this change must therefore be bugs in libva or the driver it
loads.
This reverts commit 3606602f11.
This avoids concatenation, which can't be used if the whole macro
is wrapped within another macro.
This is also arguably more readable.
Signed-off-by: Martin Storsjö <martin@martin.st>
Detecting a leap second depends on a lot of things, segment time, segment
offset, system leap second implementation, the removed part is a huge
simplification which can be misleading, so it is best to remove it.
Signed-off-by: Marton Balint <cus@passwd.hu>
Not starting a new segment if the elapsed microsecs since the start of the day
equals the the elapsed microsecs since the start of the day at the time of the
last cut seems plain wrong to me, Deti do you remember the original reason
behind this check?
Signed-off-by: Marton Balint <cus@passwd.hu>
The AVFormat stream count can be larger due external factors, such as
an id3 tag appended.
Avoid an out of bound read.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Without the /UTF-8 switch, the MSVC compiler treats all files as in the
system codepage, instead of in UTF-8, which causes UTF-8 string literals
to be interpreted wrong.
This switch was only introduced in VS2015 Update 2, and any earlier
versions do not have an equivalent solution.
Fixes fate-sub-scc on MSVC 2015+
Fixes out of array read
Fixes: 544/clusterfuzz-testcase-5936536407244800.f8bd9b24_8ba77916_70c2c7be_3df6a2ea_96cd9f14
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes ubsan warnings in non debug builds by using unsigned operations
in debug builds the correct signed operations are retained so that overflows
(which should not occur in valid files and may indicate problems in the DSP code
or decoder) can be detected.
Alternatively they can be changed to unsigned unconditionally, then its
not possible though to detect overflows easily if someone wants to test
the DSP code for overflows.
The 2nd alternative would be to leave the code as it is and accept that
there are undefined operations in the DSP code and that ubsan output is
full of them in some cases.
Similar changes would be needed in some other DSP routines
Suggested-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Clarify that setting loop=0 is required to make the stream loop infinitely, rather than saying that a value "less than 1" is needed.
Signed-off-by: Lou Logan <lou@lrcd.com>
This swaps which field is set when the Window Acknowledgement Size
and Set Peer BW packets are received, renames the fields in
order to clarify their role further and adds verbose comments
explaining their respective roles and how well the code currently
does what it is supposed to.
The Set Peer BW packet tells the receiver of the packet (which
can be either client or server) that it should not send more data
if it already has sent more data than the specified number of bytes,
without receiving acknowledgement for them. Actually checking this
limit is currently not implemented.
In order to be able to check that properly, one can send the
Window Acknowledgement Size packet, which tells the receiver of the
packet that it needs to send Acknowledgement packets
(RTMP_PT_BYTES_READ) at least after receiving a given number of bytes
since the last Acknowledgement.
Therefore, when we receive a Window Acknowledgement Size packet,
this sets the maximum number of bytes we can receive without sending
an Acknowledgement; therefore when handling this packet we should set
the receive_report_size field (previously client_report_size).
Signed-off-by: Martin Storsjö <martin@martin.st>
Also rename comments and log messages accordingly,
and add clarifying comments for some hardcoded values.
The previous names were taken from older, reverse engineered
references.
These names match the official public rtmp specification, and
matches the names used by wirecast in annotating captured
streams. These names also avoid hardcoding the roles of server
and client, since the handling of them is irrelevant of whether
we act as server or client.
The RTMP_PT_PING type maps to RTMP_PT_USER_CONTROL.
The SERVER_BW and CLIENT_BW types are a bit more intertwined;
RTMP_PT_SERVER_BW maps to RTMP_PT_WINDOW_ACK_SIZE and
RTMP_PT_CLIENT_BW maps to RTMP_PT_SET_PEER_BW.
Signed-off-by: Martin Storsjö <martin@martin.st>
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000aff8a4 in vaTerminate ()
#1 0x0000000000ae50ce in vaapi_device_free (ctx=<optimized out>) at libavutil/hwcontext_vaapi.c:882
#2 0x0000000000ae1f9e in hwdevice_ctx_free (opaque=<optimized out>, data=<optimized out>) at libavutil/hwcontext.c:66
#3 0x0000000000ad856f in buffer_replace (src=0x0, dst=0x7fffa26ef1b8) at libavutil/buffer.c:119
#4 av_buffer_unref (buf=buf@entry=0x7fffa26ef1f8) at libavutil/buffer.c:129
#5 0x0000000000ae299f in av_hwdevice_ctx_create (pdevice_ref=0x170ac50 <hw_device_ctx>, type=type@entry=AV_HWDEVICE_TYPE_VAAPI, device=<optimized out>,
opts=opts@entry=0x0, flags=flags@entry=0) at libavutil/hwcontext.c:494
#6 0x0000000000400968 in vaapi_device_init (device=<optimized out>) at ffmpeg_vaapi.c:223
Signed-off-by: Mark Thompson <sw@jkqxz.net>
Implements support for height/width expressions in vf_scale_vaapi,
by refactoring common code into a new libavfilter/scale.c
Signed-off-by: Mark Thompson <sw@jkqxz.net>
Change the encoding of the original developer name from ISO-8859-1 to UTF-8.
Remove the stale/completed TODO list.
Fix two small typos.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Weak dependencies on external libraries do not obviate having to
explicitly enable these libraries, so the weak dependency does not
simplify the configure command line nor have any real effect.
* commit '7f549b8338ed3775fec4bf10421ff5744e5866dd':
riff: don't overwrite bps from WAVEFORMATEX if EXTENSIBLE doesn't contain that data.
Only cosmetics, the change was already present.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '6135c3b61e084be93c0876cecd06f4e764f961c0':
Revert "avprobe: Zero the allocated avio buffer memory"
This commit is a noop, see 591cf8aa0e
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'ed9b2a5178d7a7c5a95694da3a808af327f36aff':
mov: Rework the check for invalid indexes in stsc
This commit is a noop, see 3c058f5701.
The proposed fix breaks seeking in multiple_stsd.mp4 (ticket #3962) and
playback of wwwq_cut.mp4 (ticket #2991).
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Certain alpha run lengths (for SHQ1/SHQ3/SHQ5) could be stored in
both long and short versions, and we would only accept the short version,
returning -1 (invalid code) for the others. This could cause an
out-of-bounds write on malicious input, as discovered by
Andreas Cadhalpun during fuzzing.
Fix by simply allowing both versions, leaving no invalid codes
in the alpha VLC.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Multichannel joint stereo simply interleaves stereo pairs (6ch: 2ch + 2ch + 2ch), so each pair is decoded separatedly.
***
To test my changes, I converted examples to wav with ffmpeg.exe (old and new), and compared them to see they are byte-exact.
Regular 2ch files (JS and normal) were straightforward to test.
For multichannel, to check each JS pair is correctly decoded separatedly I did:
- manually demux 6ch.msf into 3 pairs and convert them (2ch_1.wav + 2ch_2.wav + 2ch_3.wav)
- convert the 6ch.msf file to wav (with my changes)
- manually demux the 6ch.wav into 3 pairs (6ch_d1.wav + 6ch_d2.wav + 6ch_d3.wav)
- compare each pair (ex. 2ch_3.wav vs 6ch_d3.wav): all pairs are byte-exact.
The new code just processes each JS pair separatedly, there are no algorithm changes.
It could be improved a bit but I'm not sure about typical styles.
I've only seen 6ch .MSF (probably the AT3 spec only supports 2ch audio).
Signed-off-by: bnnm <bananaman255@gmail.com>
Fixes: u263_b-frames_1.avi
Fixes part of Ticket1536
return -1 is used here as it is used in similar code in this function, I intend
to replace it by proper error codes in the whole function.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '90bc423212396e96a02edc1118982ab7f7766a63':
mov: Wrap stsc index and count compare in a separate function
The mov_stsc_index_valid() function is replaced with a macro to prevent
signdness issues (index is not always signed, and count is always
unsigned currently).
The comparison is also adjusted to reduce the risk of overflows.
Merged-by: Clément Bœsch <u@pkh.me>
Retain the ranges of frame indexes when applying edit list in
mov_fix_index. The index ranges are then used to keep track of the frame
index of the current sample. In case of a discontinuity in frame indexes
due to edit, update the auxiliary info position accordingly.
Reviewed-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '209ee680ce99035202520b900326a57f7fa0aceb':
mov: Fix stsc_count comparison
This commit is a noop, see 3c058f5701
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'a1f6a2dfdaf9beb42ca66e49d10bfaf5905a0128':
ratecontrol: Reorder functions to avoid forward declarations
Merged, but this seems to break the clear separation of 1-pass vs
2-pass.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'd639dcdae022130078c9c84b7b691c5e9694786c':
ratecontrol: Move Xvid-related functions to the place they are actually used
Merged-by: Clément Bœsch <u@pkh.me>
No deprecation guards, because the old decode API (for which this field
is needed) doesn't have any either.
This field should be removed together with the old decode calls.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit '44972e227df0f7ad5aa9004d971fb54e9dc5c849':
ratecontrol: Move mpegenc-only function where it is used
This commit is a noop. ff_write_pass1_stats() is used in snowenc as
well.
Merged-by: Clément Bœsch <u@pkh.me>
The code relies on their validity and otherwise can try to access a NULL
object->rle pointer, causing segmentation faults.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The assumption this is based on is wrong, the code is not always run with bitexact flags
This reverts commit a956164e1e, reversing
changes made to f6005907fd.
Approved-by: James Almer <jamrial@gmail.com>
* commit 'd06dfaa5cbdd20acfd2364b16c0f4ae4ddb30a65':
x86: huffyuv: Use EXTERNAL_SSSE3_FAST convenience macro where appropriate
Merged-by: James Almer <jamrial@gmail.com>
* commit '8e9cd81d291b1010c625b2766058aadf4affb537':
x86: cpu: Detect Conroe CPUs and their slow shuffle unit
Merged-by: James Almer <jamrial@gmail.com>
* commit '7d7355aa92bb36ca0765c49a569a999bcb96f332':
x86: Add SSSE3_SLOW CPU flag and related convenience macros
Merged-by: James Almer <jamrial@gmail.com>
* commit '4efab89332ea39a77145e8b15562b981d9dbde68':
x86: Use *_FAST/*_SLOW CPU feature detection macros where appropriate
Merged-by: James Almer <jamrial@gmail.com>
* commit '0a39c9ac0bfd7345fe676b4e2707d9cec3cbb553':
x86: hpeldsp: Don't check for bitexact flag when initializing VP3-specific code
Merged-by: James Almer <jamrial@gmail.com>
* commit '1dfc3cf89d0eb026af28be46294b85d79499ffb5':
x86: hpeldsp: Split off VP3-specific bits into a separate file
Merged-by: James Almer <jamrial@gmail.com>
* commit '0e0538aefc75958ded49f5d075c99a81cf6b2bbb':
avprobe: Zero the allocated avio buffer memory
This commit is a noop, no such thing exists in ffprobe.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'e344e65109f1a75ca82aff4cecec44e79197753c':
h264dec: do not call finish_setup() if we have not started a frame
This commit is a noop, see bdbbb8f11e
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '1f7b4f9abc6bae94e576e710b8d10117ca3c8238':
h264dec: make sure not to call finish_setup() more than once per frame
This commit is a noop, see bdbbb8f11e
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'da917fcf5183ed249ad1285b8edd330f421376c4':
avconv_dxva2: add a profile check for hevc
This commit is a noop, see a655bc8344
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '1ecb63cd1c1a4ddc5efed4abbc3158b969d8c5e4':
hevc: set profile based on the profile compatibility flags if needed
This commit is a noop, see f85cc3bf12
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'fca3c3b61952aacc45e9ca54d86a762946c21942':
hevc: Add AVX2 DC IDCT
Mostly noop as we already have that code.
In the ASM, code is merged with the exception of SECTION which is kept
uppercase for consistency with the rest of the codebase.
Still in the ASM, the prototype comment is fixed to honor the '_' added
from the original commit.
idct_dc_proto() is dropped as it's not used anymore here.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'cc16da75c2f99d92f7a6461100f041352deb6d88':
hevc: Add coefficient limiting to speed up IDCT
Noop again as we have these changes already, only random spacing
changes.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '4f247de3b797cdc9d243d26534412f81c306e5b5':
hevcdsp_template: Templatize IDCT
This commit is a noop as we already have that code from a previous
commits (see 92cccb7bcd).
Spacing is adjusted to reduce the diff.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '1bd890ad173d79e7906c5e1d06bf0a06cca4519d':
hevc: Separate adding residual to prediction from IDCT
This commit should be a noop but isn't because of the following renames:
- transform_add → add_residual
- transform_skip → dequant
- idct_4x4_luma → transform_4x4_luma
Merged-by: Clément Bœsch <cboesch@gopro.com>
The code relies on their validity and otherwise can try to access a NULL
object->rle pointer, causing segmentation faults.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Allows the user to reserve space for the ODML master index. A sufficient
sized master index in the AVI header avoids storing follow-up master
indexes within the 'movi' data later. If the option is omitted or zero
the index size is estimated from output duration and bitrate.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
The string codec name need not be as long as the value we are
comparing it to, so memcmp may make decisions derived from
uninitialised data that valgrind then complains about (though the
overall result of the function will always be the same). Use
strncmp instead, which will stop at the first zero byte and
therefore not encounter this issue.
Only do this when building for a recent VAAPI version - initial
driver implementations were confused about the interpretation of the
framerate field, but hopefully this will be consistent everywhere
once 0.40.0 is released.
Default to using VBR when a target bitrate is set, unless the max rate
is also set and matches the target. Changes to the Intel driver mean
that min_qp is also respected in this case, so set a codec default to
unset the value rather than using the current default inherited from
the MPEG-4 part 2 encoder.
This includes a backward-compatibility hack to choose CBR anyway on
old drivers which have no CBR support, so that existing programs will
continue to work their options now map to VBR.
Use webm muxer for VP8, VP9 and Opus codec, mp4 muxer otherwise.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>
The dash_write function drops data, if no IOContext is initialized.
Since the mp4 muxer is used in "frag_custom" mode, data is only
written when calling av_write_frame(NULL) explicitly and thus
there will be no data loss.
To add support for webm as subordinate muxer, which doesn't have
such a mode, a dynamic buffer is required to provide an always
initialized IOContext.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously all mapped streams of a media type (video, audio) where assigned
to a single AdaptationSet. Using the DASH live profile it is mandatory, that
the segments of all representations are aligned, which is currently not
enforced. This leads to problems when using video streams with different
key frame intervals. So to play safe, default to one AdaptationSet per stream,
unless overwritten by explicit assignment.
To get the old assignment scheme, use
-adaptation_sets "id=0,streams=v id=1,streams=a"
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>
Using the characters "v" or "a" instead of stream index numbers for assigning
streams in the adaption_set option, all streams matching that given type will
be added to the AdaptationSet.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>
Also makes sure all streams are assigned to exactly one AdaptationSet.
This patch is originally based partially on code by Vignesh Venkatasubramanian.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>
Bandwidth information is required in the manifest, but not always
provided by the demuxer. In that case calculate the bandwith based
on the size and duration of the first segment.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>
The current implementation creates new segments comparing
pkt->pts - first_pts > nb_segs * min_seg_duration
This works fine, but if the keyframe interval is smaller than "min_seg_duration"
segments shorter than the minimum segment duration are created.
Example: keyint=50, min_seg_duration=3000000
segment 1 contains keyframe 1 (duration=2s < total_duration=3s)
and keyframe 2 (duration=4s >= total_duration=3s)
segment 2 contains keyframe 3 (duration=6s >= total_duration=6s)
segment 3 contains keyframe 4 (duration=8s < total_duration=9s)
and keyframe 5 (duration=10s >= total_duration=9s)
...
Segment 2 is only 2s long, shorter than min_seg_duration = 3s.
To fix this, new segments are created based on the actual written duration.
Otherwise the option name "min_seg_duration" is misleading.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Martin Storsjö <martin@martin.st>
Codec 4 (frame size 98) uses joint stereo per spec and examples.
Also removed an incorrect "align" var which wasn't used anyway (it was overwrittern).
Probably all/only .AT3 of frame size 98 are JS, too.
Signed-off-by: bnnm <bananaman255@gmail.com>
Place all temporary files within a single, quasi-atomically created
temporary directory rather than relying on unsafe 'mktemp -u'. This
prevents possible race conditions in case two parallel 'mktemp -u' calls
returned the same path. Additionally, it reduces TMPDIR pollution by
keeping all test files in a single subdirectory.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Instead of just updating statistics and leaving the work to the
call site, have it actually do the work.
Also: skip the samples by updating the frame data pointers
instead of moving the samples. More efficient and avoid writing
into shared frames.
Found-By: Muhammad Faiz <mfcc64@gmail.com>
Servers seem to be happy to receive the wrapped-around value as long
as they receive a report, otherwise they timeout.
Initially reported and analyzed by Thomas Bernhard.
Name and purpose are more appropriate there since the code isn't
an ideal example.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This allows testing EC and non EC. Avoids spending most time in EC on
high res samples and reduces the likelyhood of hitting timeouts
Fixes: Timeout in 467/fuzz-2-ffmpeg_VIDEO_AV_CODEC_ID_H263_fuzzer
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When detecting a swapped AC3 marker the data of the frame is swapped. However, in subsequent frames the data swapped is taken from the first frame rather than the current frame.
Signed-off-by: Marijn Meijles <marijn@bitpit.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
to avoid rebuffering on the clientside for difficult network conditions.
Signed-off-by: Anton Schubert <ischluff@mailbox.org>
Signed-off-by: Martin Storsjö <martin@martin.st>
Appends Z to timestamp to force ISO8601 datetime parsing as UTC.
Without Z, some browsers (Chrome) interpret the timestamp as
localtime and others (Firefox) interpret it as UTC.
Signed-off-by: Anton Schubert <ischluff@mailbox.org>
Signed-off-by: Martin Storsjö <martin@martin.st>
From e24d95c0e06a878d401ee34fd6742fcaddeeb95f Mon Sep 17 00:00:00 2001
From: Joel Cunningham <joel.cunningham@me.com>
Date: Mon, 9 Jan 2017 13:37:51 -0600
Subject: [PATCH] tcp: set socket buffer sizes before listen/connect/accept
Attempting to set SO_RCVBUF and SO_SNDBUF on TCP sockets after connection
establishment is incorrect and some stacks ignore the set call on the socket at
this point. This has been observed on MacOS/iOS. Windows 7 has some peculiar
behavior where setting SO_RCVBUF after applies only if the buffer is increasing
from the default while decreases are ignored. This is possibly how the incorrect
usage has gone unnoticed
Unix Network Programming Vol. 1: The Sockets Networking API (3rd edition, seciton 7.5):
"When setting the size of the TCP socket receive buffer, the ordering of the
function calls is important. This is because of TCP's window scale option,
which is exchanged with the peer on SYN segments when the connection is
established. For a client, this means the SO_RCVBUF socket option must be
set before calling connect. For a server, this means the socket option must
be set for the listening socket before calling listen. Setting this option
for the connected socket will have no effect whatsoever on the possible window
scale option because accept does not return with the connected socket until
TCP's three-way handshake is complete. This is why the option must be set on
the listening socket. (The sizes of the socket buffers are always inherited from
the listening socket by the newly created connected socket)"
Signed-off-by: Joel Cunningham <joel.cunningham@me.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Newer versions of OS X use the blocks extension in VDA-related headers.
Some compilers, like current gcc, do not support the blocks extension
and fail to compile code using those headers.
If we only have a target compiler but no host compiler, the $type
variable will be empty once.
(Currently we fail to do a cross build if no host compiler is available
due to using the host compiler for processing option lists though.
But despite that, this comparison in configure needs quotes.)
Signed-off-by: Martin Storsjö <martin@martin.st>
When bytes_read overflowed, last_bytes_read did not yet overflow
and no bytes-read report was created leading to a timeout.
Analyzed-by: Thomas Bernhard
Fixes ticket #5836.
Current code returned the number of channels as channel layout in that case,
and if nret is not set then unknown layouts are typically not supported.
Also use the common parsing code. Use a temporary workaround to parse an
unknown channel layout such as '13c', after a 1 year grace period only '13C'
will work.
Signed-off-by: Marton Balint <cus@passwd.hu>
Return a channel layout and the number of channels based on the specified name.
This function is similar to av_get_channel_layout(), but can also parse unknown
channel layout specifications.
Unknown channel layout specifications are a decimal number and a capital 'C'
suffix, in order to not break compatibility with the lowercase 'c' suffix,
which is used for a guessed channel layout with the specified number of
channels.
Signed-off-by: Marton Balint <cus@passwd.hu>
This work is sponsored by, and copyright, Google.
This is similar to the arm version, but due to the larger registers
on aarch64, we can do 8 pixels at a time for all filter sizes.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_loop_filter_h_4_8_10bpp_neon: 213.2 172.6
vp9_loop_filter_h_8_8_10bpp_neon: 281.2 244.2
vp9_loop_filter_h_16_8_10bpp_neon: 657.0 444.5
vp9_loop_filter_h_16_16_10bpp_neon: 1280.4 877.7
vp9_loop_filter_mix2_h_44_16_10bpp_neon: 397.7 358.0
vp9_loop_filter_mix2_h_48_16_10bpp_neon: 465.7 429.0
vp9_loop_filter_mix2_h_84_16_10bpp_neon: 465.7 428.0
vp9_loop_filter_mix2_h_88_16_10bpp_neon: 533.7 499.0
vp9_loop_filter_mix2_v_44_16_10bpp_neon: 271.5 244.0
vp9_loop_filter_mix2_v_48_16_10bpp_neon: 330.0 305.0
vp9_loop_filter_mix2_v_84_16_10bpp_neon: 329.0 306.0
vp9_loop_filter_mix2_v_88_16_10bpp_neon: 386.0 365.0
vp9_loop_filter_v_4_8_10bpp_neon: 150.0 115.2
vp9_loop_filter_v_8_8_10bpp_neon: 209.0 175.5
vp9_loop_filter_v_16_8_10bpp_neon: 492.7 345.2
vp9_loop_filter_v_16_16_10bpp_neon: 951.0 682.7
This is significantly faster than the ARM version in almost
all cases except for the mix2 functions.
Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 2-3x.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
Compared to the arm version, on aarch64 we can keep the full 8x8
transform in registers, and for 16x16 and 32x32, we can process
it in slices of 4 pixels instead of 2.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_inv_adst_adst_4x4_sub4_add_10_neon: 111.0 109.7
vp9_inv_adst_adst_8x8_sub8_add_10_neon: 914.0 733.5
vp9_inv_adst_adst_16x16_sub16_add_10_neon: 5184.0 3745.7
vp9_inv_dct_dct_4x4_sub1_add_10_neon: 65.0 65.7
vp9_inv_dct_dct_4x4_sub4_add_10_neon: 100.0 96.7
vp9_inv_dct_dct_8x8_sub1_add_10_neon: 111.0 119.7
vp9_inv_dct_dct_8x8_sub8_add_10_neon: 618.0 494.7
vp9_inv_dct_dct_16x16_sub1_add_10_neon: 295.1 284.6
vp9_inv_dct_dct_16x16_sub2_add_10_neon: 2303.2 1883.9
vp9_inv_dct_dct_16x16_sub8_add_10_neon: 2984.8 2189.3
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 3890.0 2799.4
vp9_inv_dct_dct_32x32_sub1_add_10_neon: 1044.4 1012.7
vp9_inv_dct_dct_32x32_sub2_add_10_neon: 13333.7 9695.1
vp9_inv_dct_dct_32x32_sub16_add_10_neon: 18531.3 12459.8
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 24470.7 16160.2
vp9_inv_wht_wht_4x4_sub4_add_10_neon: 83.0 79.7
The larger transforms are significantly faster than the corresponding
ARM versions.
The speedup vs C code is smaller than in 32 bit mode, probably
because the 64 bit intermediates in the C code can be expressed
more efficiently in aarch64.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This has mostly got the same differences to the 8 bit version as
in the arm version. For the horizontal filters, we do 16 pixels
in parallel as well. For the 8 pixel wide vertical filters, we can
accumulate 4 rows before storing, just as in the 8 bit version.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_avg4_10bpp_neon: 35.7 30.7
vp9_avg8_10bpp_neon: 93.5 84.7
vp9_avg16_10bpp_neon: 324.4 296.6
vp9_avg32_10bpp_neon: 1236.5 1148.2
vp9_avg64_10bpp_neon: 4639.6 4571.1
vp9_avg_8tap_smooth_4h_10bpp_neon: 130.0 128.0
vp9_avg_8tap_smooth_4hv_10bpp_neon: 440.0 440.5
vp9_avg_8tap_smooth_4v_10bpp_neon: 114.0 105.5
vp9_avg_8tap_smooth_8h_10bpp_neon: 327.0 314.0
vp9_avg_8tap_smooth_8hv_10bpp_neon: 918.7 865.4
vp9_avg_8tap_smooth_8v_10bpp_neon: 330.0 300.2
vp9_avg_8tap_smooth_16h_10bpp_neon: 1187.5 1155.5
vp9_avg_8tap_smooth_16hv_10bpp_neon: 2663.1 2591.0
vp9_avg_8tap_smooth_16v_10bpp_neon: 1107.4 1078.3
vp9_avg_8tap_smooth_64h_10bpp_neon: 17754.6 17454.7
vp9_avg_8tap_smooth_64hv_10bpp_neon: 33285.2 33001.5
vp9_avg_8tap_smooth_64v_10bpp_neon: 16066.9 16048.6
vp9_put4_10bpp_neon: 25.5 21.7
vp9_put8_10bpp_neon: 56.0 52.0
vp9_put16_10bpp_neon/armv8: 183.0 163.1
vp9_put32_10bpp_neon/armv8: 678.6 563.1
vp9_put64_10bpp_neon/armv8: 2679.9 2195.8
vp9_put_8tap_smooth_4h_10bpp_neon: 120.0 118.0
vp9_put_8tap_smooth_4hv_10bpp_neon: 435.2 435.0
vp9_put_8tap_smooth_4v_10bpp_neon: 107.0 98.2
vp9_put_8tap_smooth_8h_10bpp_neon: 303.0 290.0
vp9_put_8tap_smooth_8hv_10bpp_neon: 893.7 828.7
vp9_put_8tap_smooth_8v_10bpp_neon: 305.5 263.5
vp9_put_8tap_smooth_16h_10bpp_neon: 1089.1 1059.2
vp9_put_8tap_smooth_16hv_10bpp_neon: 2578.8 2452.4
vp9_put_8tap_smooth_16v_10bpp_neon: 1009.5 933.5
vp9_put_8tap_smooth_64h_10bpp_neon: 16223.4 15918.6
vp9_put_8tap_smooth_64hv_10bpp_neon: 32153.0 31016.2
vp9_put_8tap_smooth_64v_10bpp_neon: 14516.5 13748.1
These are generally about as fast as the corresponding ARM
routines on the same CPU (at least on the A53), in most cases
marginally faster.
The speedup vs C code is around 4-9x.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This is more in line with how it will be extended for more bitdepths.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This is pretty much similar to the 8 bpp version, but in some senses
simpler. All input pixels are 16 bits, and all intermediates also fit
in 16 bits, so there's no lengthening/narrowing in the filter at all.
For the full 16 pixel wide filter, we can only process 4 pixels at a time
(using an implementation very much similar to the one for 8 bpp),
but we can do 8 pixels at a time for the 4 and 8 pixel wide filters with
a different implementation of the core filter.
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_loop_filter_h_4_8_10bpp_neon: 1.83 2.16 1.40 2.09
vp9_loop_filter_h_8_8_10bpp_neon: 1.39 1.67 1.24 1.70
vp9_loop_filter_h_16_8_10bpp_neon: 1.56 1.47 1.10 1.81
vp9_loop_filter_h_16_16_10bpp_neon: 1.94 1.69 1.33 2.24
vp9_loop_filter_mix2_h_44_16_10bpp_neon: 2.01 2.27 1.67 2.39
vp9_loop_filter_mix2_h_48_16_10bpp_neon: 1.84 2.06 1.45 2.19
vp9_loop_filter_mix2_h_84_16_10bpp_neon: 1.89 2.20 1.47 2.29
vp9_loop_filter_mix2_h_88_16_10bpp_neon: 1.69 2.12 1.47 2.08
vp9_loop_filter_mix2_v_44_16_10bpp_neon: 3.16 3.98 2.50 4.05
vp9_loop_filter_mix2_v_48_16_10bpp_neon: 2.84 3.64 2.25 3.77
vp9_loop_filter_mix2_v_84_16_10bpp_neon: 2.65 3.45 2.16 3.54
vp9_loop_filter_mix2_v_88_16_10bpp_neon: 2.55 3.30 2.16 3.55
vp9_loop_filter_v_4_8_10bpp_neon: 2.85 3.97 2.24 3.68
vp9_loop_filter_v_8_8_10bpp_neon: 2.27 3.19 1.96 3.08
vp9_loop_filter_v_16_8_10bpp_neon: 3.42 2.74 2.26 4.40
vp9_loop_filter_v_16_16_10bpp_neon: 2.86 2.44 1.93 3.88
The speedup vs C code measured in checkasm is around 1.1-4x.
These numbers are quite inconclusive though, since the checkasm test
runs multiple filterings on top of each other, so later rounds might
end up with different codepaths (different decisions on which filter
to apply, based on input pixel differences).
Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 2-4x.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This is structured similarly to the 8 bit version. In the 8 bit
version, the coefficients are 16 bits, and intermediates are 32 bits.
Here, the coefficients are 32 bit. For the 4x4 transforms for 10 bit
content, the intermediates also fit in 32 bits, but for all other
transforms (4x4 for 12 bit content, and 8x8 and larger for both 10
and 12 bit) the intermediates are 64 bit.
For the existing 8 bit case, the 8x8 transform fit all coefficients in
registers; for 10/12 bit, when the coefficients are 32 bit, the 8x8
transform also has to be done in slices of 4 pixels (just as 16x16 and
32x32 for 8 bit).
The slice width also shrinks from 4 elements to 2 elements in parallel
for the 16x16 and 32x32 cases.
The 16 bit coefficients from idct_coeffs and similar tables also need
to be lenghtened to 32 bit in order to be used in multiplication with
vectors with 32 bit elements. This leads to the fixed coefficient
vectors needing more space, leading to more cases where they have to
be reloaded within the transform (in iadst16).
This technically would need testing in checkasm for subpartitions
in increments of 2, but that slows down normal checkasm runs
excessively.
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_inv_adst_adst_4x4_sub4_add_10_neon: 4.83 11.36 5.22 6.77
vp9_inv_adst_adst_8x8_sub8_add_10_neon: 4.12 7.60 4.06 4.84
vp9_inv_adst_adst_16x16_sub16_add_10_neon: 3.93 8.16 4.52 5.35
vp9_inv_dct_dct_4x4_sub1_add_10_neon: 1.36 2.57 1.41 1.61
vp9_inv_dct_dct_4x4_sub4_add_10_neon: 4.24 8.66 5.06 5.81
vp9_inv_dct_dct_8x8_sub1_add_10_neon: 2.63 4.18 1.68 2.87
vp9_inv_dct_dct_8x8_sub4_add_10_neon: 4.52 9.47 4.24 5.39
vp9_inv_dct_dct_8x8_sub8_add_10_neon: 3.45 7.34 3.45 4.30
vp9_inv_dct_dct_16x16_sub1_add_10_neon: 3.56 6.21 2.47 4.32
vp9_inv_dct_dct_16x16_sub2_add_10_neon: 5.68 12.73 5.28 7.07
vp9_inv_dct_dct_16x16_sub8_add_10_neon: 4.42 9.28 4.24 5.45
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 3.41 7.29 3.35 4.19
vp9_inv_dct_dct_32x32_sub1_add_10_neon: 4.52 8.35 3.83 6.40
vp9_inv_dct_dct_32x32_sub2_add_10_neon: 5.86 13.19 6.14 7.04
vp9_inv_dct_dct_32x32_sub16_add_10_neon: 4.29 8.11 4.59 5.06
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 3.31 5.70 3.56 3.84
vp9_inv_wht_wht_4x4_sub4_add_10_neon: 1.89 2.80 1.82 1.97
The speedup compared to the C functions is around 1.3 to 7x for the
full transforms, even higher for the smaller subpartitions.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
The plain pixel put/copy functions are used from the 8 bit version,
for the double size (e.g. put16 uses ff_vp9_copy32_neon), and a new
copy128 is added.
Compared with the 8 bit version, the filters can no longer use the
trick to accumulate in 16 bit with only saturation at the end, but now
the accumulators need to be 32 bit. This avoids the need to keep track
of which filter index is the largest though, reducing the size of the
executable code for these filters.
For the horizontal filters, we only do 4 or 8 pixels wide in parallel
(while doing two rows at a time), since we don't have enough register
space to filter 16 pixels wide.
For the vertical filters, we still do 4 and 8 pixels in parallel just
as in the 8 bit case, but we need to store the output after every 2
rows instead of after every 4 rows.
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_avg4_10bpp_neon: 2.25 2.44 3.05 2.16
vp9_avg8_10bpp_neon: 3.66 8.48 3.86 3.50
vp9_avg16_10bpp_neon: 3.39 8.26 3.37 2.72
vp9_avg32_10bpp_neon: 4.03 10.20 4.07 3.42
vp9_avg64_10bpp_neon: 4.15 10.01 4.13 3.70
vp9_avg_8tap_smooth_4h_10bpp_neon: 3.38 6.22 3.41 4.75
vp9_avg_8tap_smooth_4hv_10bpp_neon: 3.89 6.39 4.30 5.32
vp9_avg_8tap_smooth_4v_10bpp_neon: 5.32 9.73 6.34 7.31
vp9_avg_8tap_smooth_8h_10bpp_neon: 4.45 9.40 4.68 6.87
vp9_avg_8tap_smooth_8hv_10bpp_neon: 4.64 8.91 5.44 6.47
vp9_avg_8tap_smooth_8v_10bpp_neon: 6.44 13.42 8.68 8.79
vp9_avg_8tap_smooth_64h_10bpp_neon: 4.66 9.02 4.84 7.71
vp9_avg_8tap_smooth_64hv_10bpp_neon: 4.61 9.14 4.92 7.10
vp9_avg_8tap_smooth_64v_10bpp_neon: 6.90 14.13 9.57 10.41
vp9_put4_10bpp_neon: 1.33 1.46 2.09 1.33
vp9_put8_10bpp_neon: 1.57 3.42 1.83 1.84
vp9_put16_10bpp_neon: 1.55 4.78 2.17 1.89
vp9_put32_10bpp_neon: 2.06 5.35 2.14 2.30
vp9_put64_10bpp_neon: 3.00 2.41 1.95 1.66
vp9_put_8tap_smooth_4h_10bpp_neon: 3.19 5.81 3.31 4.63
vp9_put_8tap_smooth_4hv_10bpp_neon: 3.86 6.22 4.32 5.21
vp9_put_8tap_smooth_4v_10bpp_neon: 5.40 9.77 6.08 7.21
vp9_put_8tap_smooth_8h_10bpp_neon: 4.22 8.41 4.46 6.63
vp9_put_8tap_smooth_8hv_10bpp_neon: 4.56 8.51 5.39 6.25
vp9_put_8tap_smooth_8v_10bpp_neon: 6.60 12.43 8.17 8.89
vp9_put_8tap_smooth_64h_10bpp_neon: 4.41 8.59 4.54 7.49
vp9_put_8tap_smooth_64hv_10bpp_neon: 4.43 8.58 5.34 6.63
vp9_put_8tap_smooth_64v_10bpp_neon: 7.26 13.92 9.27 10.92
For the larger 8tap filters, the speedup vs C code is around 4-14x.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This is more in line with how it will be extended for more bitdepths.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'fd5e6a095f69495c558069315d6b36ea410c31fa':
x86util: Extend SPLATW for avx2
This commit is a noop, see 1ace9573dc
(only libavutil/x86/x86util.asm chunk).
Merged-by: Clément Bœsch <u@pkh.me>
* commit '37961044c6':
checkasm: arm: Ignore changes to bits 0-4 and 7 of FPSCR
cheackasm/arm: remove NEON instructions from checkasm_checked_call_vfp
checkasm: arm: Don't start new const blocks for each string
This merge is a noop: the changes were included in 9f1c81e5ec.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5ece6911010b3464d2fdacfa8031c15b5bd83418':
apichanges: Fill in missing hashes and dates
This commit is a noop as we need to fill with our own hashes.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'facdfe40805559963b5875931af9406ed5ddcd5c':
swscale: Add proper ff_ prefix to init functions
This commit is a noop, see e8c3716064
I'm keeping our ff_sws_ vs ff_ since we use ff_sws_ in other places in
swscale.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'c0fd2fb27bebd1d5ab028e6df6bca9119d269122':
swscale: Rename sws_context_class to ff_sws_context_class
This commit is a noop, see 8bfbc8c5e5
Merged-by: Clément Bœsch <u@pkh.me>
* commit '71a0472114574993df7035f4de9aa007e03817b8':
checkasm: arm: report the first clobbered register in checkasm_checked_call
Also includes 446353ea18, 59aeed93e4, and 37961044c6 to avoid breaking
too much stuff.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'a8fce24b9c5a87187f5bd864b18f5b3e575f8c3d':
avconv_dxva2: support HEVC Main10 decoding
This commit is a noop, see 1ec14612a5
Merged-by: Clément Bœsch <u@pkh.me>
* commit '33f6690eb4e21acc4b581688eecfc4cc5ea9515e':
hevc: offer DXVA2 for 10bit 420
This commit is a noop, see ccb94789e2
Merged-by: Clément Bœsch <u@pkh.me>
* commit '38efff92f1ef81f3de20ff0460ec7b70c253d714':
FATE: add a test for H.264 with two fields per packet
h264: fix decoding multiple fields per packet with slice threads
This merge includes two commits because the FATE test was useful in
order to make proper testing.
The merge gets rid of the now unused:
- SLICE_SINGLETHREAD and SLICE_SKIPED macros
- max_contexts
- "again" label in decode_nal_units()
This commit also includes the fix from d3e4d406b.
Thanks to wm4 and Michael Niedermayer for their testing.
Merged-by: Clément Bœsch <u@pkh.me>
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
This treats the case of no slices like no frames which it basically is.
The field is added to the context as other nal related fields are also there
and passing the has_slices field per *arguments is ugly and not consistent
Found-by: ubitux
Approved-by: ubitux
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If fifo is enabled on tee muxer, ffmpeg exits because of an unknown option passed to fifo muxer.
Option name "format_options" was replaced by "format_opts" on tee muxer.
Signed-off-by: Felipe Astroza <felipe@astroza.cl>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
CUVID on GeForce GT 730 and GeForce GTX 1060 does not report any error when
decoding 8K h264 packets. However, it does return an error during
cuvidCreateDecoder call if the indicated video resolution is not
supported.
Given that stream resolution is typically known as a result of probing
it is better to use this information during avcodec_open2 call to fail
immediately, rather than proceeding to decode and never receiving any
frames from the decoder nor receiving any indication of decode failure.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This happens because segment_end() returns an error, so seg_write_packet
never proceeds to segment_start(), and seg->avf->pb is never re-set,
so we crash with a null pb when av_write_trailer flushes the packet
queue.
This doesn't seem to be clearly recoverable, so I'm just failing more
gracefully.
Repro:
ffmpeg -i input.ts -f segment -c copy -segment_list /noaxx.m3u8 test-%05d.ts
(assuming you don't have write access to /)
This makes the code 7 times faster with the testcase from libfuzzer
and should reduce the amount of timeouts we hit in automated fuzzing.
(for example 438/fuzz-2-ffmpeg_VIDEO_AV_CODEC_ID_RV40_fuzzer)
The code is also faster with more realistic input though the difference
is small here as that is far from the worst cases the fuzzers pick out
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
use av_lfg_init_from_data() to seed AC-3 dithering from the AC-3 frame
data to make it consistent given the same AC-3 frame, if option is set.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Raises max channels to 6 (for non joint-stereo only),
there is no difference decoding 1 or N discrete channels.
Fixes trac issue #5840
Signed-off-by: bnnm <bananaman255@gmail.com>
When use http method to delete the old segments,
there is only io_open, hove not io_close yet,
this patch is used to fix it
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
when push hls to http server, the old segemnts can not delete by hls formats.
so add the http option into hls_delete_old_segments
Reported-by: Yin Jiaoyuan <yinjiaoyuan@163.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Moves much of the setup logic for VAAPI decoding into lavc; the user
now need only provide the hw_frames_ctx.
(cherry picked from commit 123ccd07c5)
(cherry picked from commit 5e879b54a3)
(cherry picked from commit 0aec37e625)
(cherry picked from commit cfa4eb4fba)
* commit 'f450cc7bc595155bacdb9f5d2414a076ccf81b4a':
h264: eliminate decode_postinit()
Also includes fixes from 1f7b4f9abc and e344e65109.
Original patch replace H264Context.next_output_pic (H264Picture *) by
H264Context.output_frame (AVFrame *). This change is discarded as it
is incompatible with the frame reconstruction and motion vectors
display code which needs the extra information from the H264Picture.
Merged-by: Clément Bœsch <u@pkh.me>
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
We can pick the correct slice index directly from the ID3D11VideoDecoderOutputView
casted from data[3].
Also added myself as maintainer for DXVA2 and D3D11VA.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
No need to loop through the known surfaces, we'll use the requested surface
anyway.
The loop is only done for DXVA2.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When support for this was added the details weren't yet finalized.
This is no longer the case.
Fixes writing of mkv/webm files with HDR.
Reported-by: Kagami Hiiragi <kagami@genshiken.org>
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Reviewed-by: James Almer <jamrial@gmail.com>
This work is sponsored by, and copyright, Google.
Previously all subpartitions except the eob=1 (DC) case ran with
the same runtime:
vp9_inv_dct_dct_16x16_sub16_add_neon: 1373.2
vp9_inv_dct_dct_32x32_sub32_add_neon: 8089.0
By skipping individual 8x16 or 8x32 pixel slices in the first pass,
we reduce the runtime of these functions like this:
vp9_inv_dct_dct_16x16_sub1_add_neon: 235.3
vp9_inv_dct_dct_16x16_sub2_add_neon: 1036.7
vp9_inv_dct_dct_16x16_sub4_add_neon: 1036.7
vp9_inv_dct_dct_16x16_sub8_add_neon: 1036.7
vp9_inv_dct_dct_16x16_sub12_add_neon: 1372.1
vp9_inv_dct_dct_16x16_sub16_add_neon: 1372.1
vp9_inv_dct_dct_32x32_sub1_add_neon: 555.1
vp9_inv_dct_dct_32x32_sub2_add_neon: 5190.2
vp9_inv_dct_dct_32x32_sub4_add_neon: 5180.0
vp9_inv_dct_dct_32x32_sub8_add_neon: 5183.1
vp9_inv_dct_dct_32x32_sub12_add_neon: 6161.5
vp9_inv_dct_dct_32x32_sub16_add_neon: 6155.5
vp9_inv_dct_dct_32x32_sub20_add_neon: 7136.3
vp9_inv_dct_dct_32x32_sub24_add_neon: 7128.4
vp9_inv_dct_dct_32x32_sub28_add_neon: 8098.9
vp9_inv_dct_dct_32x32_sub32_add_neon: 8098.8
I.e. in general a very minor overhead for the full subpartition case due
to the additional cmps, but a significant speedup for the cases when we
only need to process a small part of the actual input data.
This is cherrypicked from libav commits
cad42fadcd and
a0c443a398.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This work is sponsored by, and copyright, Google.
Previously all subpartitions except the eob=1 (DC) case ran with
the same runtime:
Cortex A7 A8 A9 A53
vp9_inv_dct_dct_16x16_sub16_add_neon: 3188.1 2435.4 2499.0 1969.0
vp9_inv_dct_dct_32x32_sub32_add_neon: 18531.7 16582.3 14207.6 12000.3
By skipping individual 4x16 or 4x32 pixel slices in the first pass,
we reduce the runtime of these functions like this:
vp9_inv_dct_dct_16x16_sub1_add_neon: 274.6 189.5 211.7 235.8
vp9_inv_dct_dct_16x16_sub2_add_neon: 2064.0 1534.8 1719.4 1248.7
vp9_inv_dct_dct_16x16_sub4_add_neon: 2135.0 1477.2 1736.3 1249.5
vp9_inv_dct_dct_16x16_sub8_add_neon: 2446.7 1828.7 1993.6 1494.7
vp9_inv_dct_dct_16x16_sub12_add_neon: 2832.4 2118.3 2266.5 1735.1
vp9_inv_dct_dct_16x16_sub16_add_neon: 3211.7 2475.3 2523.5 1983.1
vp9_inv_dct_dct_32x32_sub1_add_neon: 756.2 456.7 862.0 553.9
vp9_inv_dct_dct_32x32_sub2_add_neon: 10682.2 8190.4 8539.2 6762.5
vp9_inv_dct_dct_32x32_sub4_add_neon: 10813.5 8014.9 8518.3 6762.8
vp9_inv_dct_dct_32x32_sub8_add_neon: 11859.6 9313.0 9347.4 7514.5
vp9_inv_dct_dct_32x32_sub12_add_neon: 12946.6 10752.4 10192.2 8280.2
vp9_inv_dct_dct_32x32_sub16_add_neon: 14074.6 11946.5 11001.4 9008.6
vp9_inv_dct_dct_32x32_sub20_add_neon: 15269.9 13662.7 11816.1 9762.6
vp9_inv_dct_dct_32x32_sub24_add_neon: 16327.9 14940.1 12626.7 10516.0
vp9_inv_dct_dct_32x32_sub28_add_neon: 17462.7 15776.1 13446.2 11264.7
vp9_inv_dct_dct_32x32_sub32_add_neon: 18575.5 17157.0 14249.3 12015.1
I.e. in general a very minor overhead for the full subpartition case due
to the additional loads and cmps, but a significant speedup for the cases
when we only need to process a small part of the actual input data.
In common VP9 content in a few inspected clips, 70-90% of the non-dc-only
16x16 and 32x32 IDCTs only have nonzero coefficients in the upper left
8x8 or 16x16 subpartitions respectively.
This is cherrypicked from libav commit
9c8bc74c2b.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This avoids reloading them if they haven't been clobbered, if the
first pass also was idct.
This is similar to what was done in the aarch64 version.
This is cherrypicked from libav commit
3c87039a40.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Since the same parameter is used for both input and output,
the name inout is more fitting.
This matches the naming used below in the dmbutterfly macro.
This is cherrypicked from libav commit
79566ec8c7.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The clobbering tests in checkasm are only invoked when testing
correctness, so this bug didn't show up when benchmarking the
dc-only version.
This is cherrypicked from libav commit
4d960a1185.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is one instruction less for thumb, and only have got
1/2 arm/thumb specific instructions.
This is cherrypicked from libav commit
e5b0fc170f.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The latter is 1 cycle faster on a cortex-53 and since the operands are
bytewise (or larger) bitmask (impossible to overflow to zero) both are
equivalent.
This is cherrypicked from libav commit
e7ae8f7a71.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Since aarch64 has enough free general purpose registers use them to
branch to the appropiate storage code. 1-2 cycles faster for the
functions using loop_filter 8/16, ... on a cortex-a53. Mixed results
(up to 2 cycles faster/slower) on a cortex-a57.
This is cherrypicked from libav commit
d7595de0b2.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Seemingly ff_clear_block_sse assumed that the block array is aligned,
so make sure it is.
Fixes ticket #6079
Signed-off-by: James Almer <jamrial@gmail.com>
when hlsenc use flag second_level_segment_index,
second_level_segment_size and second_level_segment_duration,
the rename is ok but the output filename always use the old filename
so move the rename operation after the close the ts file and
before open new segment
Reported-by: Christian Johannesen <chrisjohannesen@gmail.com>
Reviewed-by: Bodecs Bela <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
CID: 1396852
check the devices_list alloc status,
and release the devices_list when alloc devices error
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
The current condition can trigger in cases where it shouldn't, with
unexpected results.
Make sure that:
- container cropping is really based on the original dimensions from the
caller
- those dimenions are discarded on size change
The code is still quite hacky and eventually should be deprecated and
removed, with the decision about which cropping is used delegated to the
caller.
Introducing enforced sync points in arbitrary places is bad for
performance. Since the vast majority of receiving code (QSV VPP or
encoders, retrieving frames through hwcontext) will do the syncing, this
change should not be visible to most callers. But bumping micro just in
case.
This is also consistent with what VAAPI hwaccel does.
We can pick the correct slice index directly from the ID3D11VideoDecoderOutputView
casted from data[3].
Signed-off-by: Anton Khirnov <anton@khirnov.net>
No need to loop through the known surfaces, we'll use the requested surface
anyway.
The loop is only done for DXVA2.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
avfilter_graph_request_oldest() does work that should be done by
either the filter or the application.
The principle of this function, calling ff_request_frame() from
outside the filter was always shaky. This version is less elegant
since it requires making special cases for each filter, but it
is more robust since it no longer calls ff_request_frame()
directly without notifying the filter.
Eventually, avfilter_graph_request_oldest() will be deprecated
for a function to just run the graph.
Unlike av_frame_is_writable(), it uses the link's alloc callback,
making direct rendering possible.
The code comes from ff_filter_frame_framed(), moved with mostly
trivial changes.
start_number option starts the playlist sequence number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to specify start_number source parameter by
introducing hls_start_number_source with 3 possible values:
generic/epoch/datetime. This ensures to set start sequence number
automatically for practically unique numbers. Generic option is the
default and this is the curent behaviour: start_number option value
specifies the start sequence number. (start_number default value is 0)
If hls_start_number_source is set to epoch, then the start number will
be the seconds since epoch (1970-01-01 00:00:00). If set to datetime,
then the start sequence number will be based on the current date/time
value as YYYYmmddHHMMSS. e.g. 20161231235659.
Hls speficication allows 64 bit integers as sequence numbers. This patch
also changes some code where only 32 bit integer values were handled
correctly.
Reviewed-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Before this change, it was possible to overflow pic_order_cnt_lsb and
generate a stream with invalid POC numbering. This makes sure that
the field is large enough that a single IDR B* P sequence uses fewer
than half the available POC lsb values.
This change makes the configured GOP size be respected exactly -
previously the value could be exceeded slightly due to flaws in the
frame type selection logic.
Reason: For some cases, such as 2 or more graphics cards existing, the
default command line may fail because ffmpeg does not open the correct
device node:
ffmpeg -hwaccel qsv -c:v h264_qsv -i test.264 -c:v h264_qsv out.264
Let user choose the proper one by running like below:
ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD128 -c:v h264_qsv \
-i test.264 -c:v h264_qsv out.264
Signed-off-by: ChaoX A Liu <chaox.a.liu@gmail.com>
Signed-off-by: Huang, Zhengxu <zhengxu.maxwell@gmail.com>
Signed-off-by: Andrew, Zhang <huazh407@gmail.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
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.
This is what gimp, ImageMagick and FreeImage do and what the
Adobe Photoshop file format specification suggests.
Fixes a sample from ticket #6045.
Reviewed-by: Martin Vignali
when the segments largest duration value is look like 4.000000, the
EXT-X-TARGETDURATION value should equ 4.
it's wrong when hlsenc use ceil, so fix it.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
cid: 1396268
when av_strdup(str) error, the lst need release
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
This should make no difference as the value should not be able to be that large
but its more correct this way
Fixes CID1348138
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When allocating stack space with an alignment requirement that is larger
than the current stack alignment we need to store a copy of the original
stack pointer in order to be able to restore it later.
If we chose to use another register for this purpose we should not pick
eax/rax since it can be overwritten as a return value.
When allocating stack space with an alignment requirement that is larger
than the current stack alignment we need to store a copy of the original
stack pointer in order to be able to restore it later.
If we chose to use another register for this purpose we should not pick
eax/rax since it can be overwritten as a return value.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
When building DLLs with MSVC, CONFIG_STATIC is disabled (see
d66c52c2b3 for a more verbose explanation) since the built
object files can't be linked statically (which checkasm does).
This worked up until recently, only by luck.
Signed-off-by: Martin Storsjö <martin@martin.st>
Disable B frames when using baseline/constrained baseline profile,
following H.264 spec Annex A.2.1.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Yi A Wang <yi.a.wang@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
When the command line for children is created, it is assumed that
my_program_name always ends with "ffserver", which doesn't have to
be true if ffserver is called through a symbolic link.
In such a case, it could be that not enough space for "ffmpeg" is
available at the end, leading to a buffer overflow.
One example would be:
$ ln -s /usr/bin/ffserver ~/f; ~/f
As this is only a local buffer overflow, i.e. is based on a weird
program call, this has NO security impact.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The following three commits created a regression by writing initially
invalid mkv headers:
650e17d88b avformat/matroskaenc: write a
CRC32 element on Tags
3bcadf8227 avformat/matroskaenc: write a
CRC32 element on Info
ee888cfbe7 avformat/matroskaenc: postpone
writing the Tracks master
Symptoms:
- You can no longer playback a file that is still processed by ffmpeg,
e.g. VLC fails playback
- You can no longer stream a file to a client while if is still being
processed
- Various diagnosing tools show header errors or incomplete headers
(e.g. ffprobe, mediainfo, mkvalidator)
Note: The symptoms do not apply to completed files or ffmpeg runs that
were interrupted with 'q'
Cause:
The mentioned commits made changes in a way that some header elements
are only partially written in
mkv_write_header, leaving the header in an invalid state. Only in
mkv_write_trailer, these elements
are finished correctly, but that does only occur at the end of the
process.
Regression:
Before these commits were applied, mkv headers have always been valid,
even before completion of ffmpeg.
This has worked reliably over many versions of ffmpeg, to it was an
obvious regression.
Bugtracker:
This issue has been recorded as #5977 which is resolved by this patch
Patch:
The patch adds a new function 'end_ebml_master_crc32_preliminary' that
preliminarily finishes the ebml
element without destroying the buffer. The buffer can be used to update
the ebml element later during
mkv_write_trailer. But most important: mkv_write_header finishes with a
valid mkv header again.
Signed-off-by: James Almer <jamrial@gmail.com>
This commit adds the avio_get_dyn_buf function which allows accessing
the
content of a DynBuffer without destroying it.
This is required in matroskaenc for preliminary writing (correct) mkv
headers.
Context for this change is fixing regression bug #5977.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
looks like there is a bug in commit
1a08758e7c relating to the handling of
ptr in decode_frame after decode_block is called, before this commit
ptr would have been incremented for each line in the data window, now
after the commit it is left at the start of the first included line
rather than the line after the data window then the code sets the
remaining lines to 0 and thus the whole image is over written.
Fix by adjusting ptr to the correct line after decode_block returns
Signed-off-by: Kevin Wheatley <kevin.j.wheatley@gmail.com>
This commit replaces the current inefficient non-power-of-two FFT with a
much faster FFT based on the Prime Factor Algorithm.
Although it is already much faster than the old algorithm without SIMD,
the new algorithm makes use of the already very throughouly SIMD'd power
of two FFT, which improves performance even more across all platforms
which we have SIMD support for.
Most of the work was done by Peter Barfuss, who passed the code to me to
implement into the iMDCT and the current codebase. The code for a
5-point and 15-point FFT was derived from the previous implementation,
although it was optimized and simplified, which will make its future
SIMD easier. The 15-point FFT is currently using 6% of the current
overall decoder overhead.
The FFT can now easily be used as a forward transform by simply not
multiplying the 5-point FFT's imaginary component by -1 (which comes
from the fact that changing the complex exponential's angle by -1 also
changes the output by that) and by multiplying the "theta" angle of the
main exptab by -1. Hence the deliberately left multiplication by -1 at
the end.
FATE passes, and performance reports on other platforms/CPUs are
welcome.
Performance comparisons:
iMDCT, PFA:
101127 decicycles in speed, 32765 runs, 3 skips
iMDCT, Old:
211022 decicycles in speed, 32768 runs, 0 skips
Standalone FFT, 300000 transforms of size 960:
PFA Old FFT kiss_fft libfftw3f
3.659695s, 15.726912s, 13.300789s, 1.182222s
Being only 3x slower than libfftw3f is a big achievement by itself.
There appears to be something capping the performance in the iMDCT side
of things, possibly during the pre-stage reindexing. However, it is
certainly fast enough for now.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Prep work for the next commit, which will add a new FFT algorithm
which makes the iMDCT over 3x faster than it is currently (standalone,
the FFT is with some framesizes over 10x faster).
The new FFT algorithm uses the already thouroughly SIMD'd power of two
FFT which already has SIMD for AArch64, so users of that platform will
still see an improvement.
The previous FFT+SIMD was barely 2.5x faster than the C versions on these
platforms.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
CID: 1398228
Passing null pointer dirname to strlen, which dereferences it.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
in get_default_pattern_localtime_fmt the default pattern contains
%Y%m%d%H%I%S but the original intention was %Y%m%d%H%M%S
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
fix CID: 1398364 Resource leak
refine the code of the new options
Reviewed-by: Bodecs Bela <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
If a read fails, the current code will free the data but leave the size
non-zero. Make sure the size is zeroed in such a case.
CC: libav-stable@libav.org
Bug-Id: 1001
Found-By: Kamil Frankowicz
Signed-off-by: Sean McGovern <gseanmcg@gmail.com>
A wrong, unitialized variable is used for testing. This patch fixes this
typo.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
In H.264 section 8.2.1, we have that "The bitstream shall not contain
data that result in Min(TopFieldOrderCnt, BottomFieldOrderCnt) not
equal to 0 for a coded IDR frame". This fixes the encoder to always
conform to this - previously the POC values formed an unbroken
sequence, not resetting to zero on IDR frames.
Signed-off-by: Mark Thompson <sw@jkqxz.net>
1st:
This patch makes it possible to put actual segment file size (measured
in bytes) and/or duration (calculated in microseconds) into segment
filenames. This feature is useful when post-processing live streaming
access log files. New behaviour works only when -use_localtime option
is set and second_level_segment_size or/and
second_level_segment_duration new hls_flags are specified. %%s is the
placeholder for size and %%t for duration in hls_segment_filename
option. Fix sized trailing zeropadding also works eg. %%09s or %%023t.
A command to test new features:
./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 -f
lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac
-cutoff 20000 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags
second_level_segment_index+second_level_segment_size+second_level_segment_duration
-use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename
"segment_%Y%m%d%H%M%S_%%04d_%%08s_%%013t.ts" stream.m3u8
2nd:
doc/muxers: beside second_level_segment_duration and second_level_segment_size,
added some more details and example to hls_segment_filename,
use_localtime, use_localtime_mkdir, hls_flags. hls_flags option list
reformatted to table
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
if the http server don't response the http command,
then the thread will be blocked and never be interrupted.
Reported-by: yinyunjiang <yinyunjiang1991@qq.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Round qpIntra and qpInter calculation instead of old floor behavior.
Adopted from vaapi_encode_h264.c
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Current implementation of finding duplicate segment filenames may fail
if use_localtime_mkdir and use_localtime are in effect and
segment_filename option expression contains subdirectories with
date/time specifiers. This patch fixes this false behaviour.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
in hlcenc.c, in the hls_write_header() function the default format
string for strftime() function contains %s specifier when use_localtime
is true. This %s specifier will insert the seconds since EPOCH. But %s
is not available on all system/environment. This patch check %s
availabilty at runtine and alter the default format string if necessary.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
cutoff is implemented as an option global to lavc, but supported only
by a few encoders. This fact is now reflected in its documentation. ac3's
support of this option is added for completeness.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Pass the cutoff option from lavc's avcodec_options[] to libmp3lame's
lowpass option, without allowing to adjust its default behavior.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Prevents memory leak when read_samples_from_audio_fifo() is
called more than once by deallocating before reallocating
more memory.
Fixes space indentation for contents in ERROR().
Signed-off-by: Thomas Turner <thomastdt@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Old ICC verions don't advertise having a full C11 implementation but
may nonetheless include a feature-incomplete stdatomic.h header.
Fixes ticket #6049
Signed-off-by: James Almer <jamrial@gmail.com>
In ff_index_search_timestamp(), if b == num_entries,
m == num_entries - 1, and entries[m].flags & AVINDEX_DISCARD_FRAME is
true, then the search for the next non-discarded packet could access
entries[nb_entries], exceeding its bounds. This change adds a protection
against that scenario. Reference: https://crbug.com/666770
Reviewed-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Use a tab instead of two spaces, skip the fate prefix for the test name.
This makes IGNORE line fit in even better with the other make printouts.
Signed-off-by: Martin Storsjö <martin@martin.st>
Otherwise the .rep file would still contain a signal instead of a
zero, even if the process returned success.
Signed-off-by: Martin Storsjö <martin@martin.st>
When delete_segments hls_flag is specified, deleting old segments may
fail in certain cases when use_localtime_mkdir is in effect and
hls_segment_filename expression contains subdirs. This patch fixes this
behaviour.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
This can be useful to filter out noise in known-broken scenarios like
miscompilation by legacy compilers and similar.
Originally based on a patch by Diego Biurrun.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Additional/Modified FATE tests improve code coverage from 63.7% to 98.1%.
Changed fate-suite sample files:
* filter/hdcd-mix.flac (958K) added. It is a much better test than
filter/hdcd.flac (910K), which is now unused, but can't be removed.
* filter/hdcd-fake20bit.flac (168K) added. It is the first second of
filter/hdcd.flac, with the 16-bit LSB copied into bit 20 of a 24-bit
stream. There isn't an actual non-16-bit HDCD sample available to test.
Signed-off-by: Burt P <pburt0@gmail.com>
The checked bitstream reader does that already. To allow parsing of
superframes split over a packet boundary, we always decode the last
superframe in each packet at the start of the next packet, even if
theoretically we could have decoded it. The last superframe in the
last packet is decoded using AV_CODEC_CAP_DELAY.
in filenames
Putting date/time values into segment filenames is very usefull.
But to produce non-conflicting segment filenames with -use_localtime
option with date/time
values in hls_segment_filename option, sometimes is not enough.
Like in cases when multiple segments produced in the same second.
But hlsenc currently does not make possible to use segment index (%d) at
the
same time whe use_localtime is in effect, due to identifier conflict.
This patch makes possible to use strftime identifiers and still put
segment index (%d) at same time in segment filenames by introducing
second_level_segment_index flag. When -use_localtime is active,
identifier %d is for month day index, so %%d is the segment index
placeholder. This enhanced behaviour only exists when new
second_level_segment_index flag is specified.
For instance putting 'segment_%Y%m%d%H%M%S_%%05d.ts' value into
-hls_segment_filename option and specifing -hls_flags
second_level_segment_index and -use_localtime 1, may produce segment
filename as 'segment_20161230235758_00002.ts'
An example:
ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 -f
lavfi -i anullsrc=r=44100:cl=stereo -c:v mpeg2video -g 25 -acodec aac
-cutoff 20000 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags delete_segments+second_level_segment_index -use_localtime 1
-hls_segment_filename "segment_%Y%m%d%H%M%S_%%05d.ts" stream.m3u8
will produce segments filenames:
....
segment_20161227005902_00013.ts
segment_20161227005902_00014.ts
segment_20161227005902_00015.ts
segment_20161227005903_00016.ts
segment_20161227005903_00017.ts
segment_20161227005903_00018.ts
segment_20161227005903_00019.ts
segment_20161227005903_00020.ts
....
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
initial_prog_date_time shouldn't be adjusted when deleting segments
from disk, but rather when segments are removed from the playlist.
Signed-off-by: Jesper Ek <deadbeef84@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
It is now bitexact with the ssse3 and sse4.1 versions of the function.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
ffmpeg-devel
with use_localtime parameter hlsenc may produce identical filenames for
different but still existing segments. It happens when
hls_segment_filename contains
syntacticaly correct but inadequate format parameters. Currently there
is no any log message when such a situaton occurs but these cases should
be avoided in most times. This patch generate warning log messages in
these cases.
ticketID: #6043
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lingjiujianke@gmail.com>
This should fix issues on BSD
CLOCKS_PER_SEC is 128 on BSD while SUSv2 requires it to be a million
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes pts gaps when reading AVI files > 256GiB generated by FFmpeg.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A negative chunk size is illegal and would end up used as
length for memcpy, where it would lead to memory accesses
out of bounds.
Found-by: Paul Cher <paulcher@icloud.com>
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
With min_samples, if a frame arrives but is too small, it clears
frame_wanted_out. In most cases, the destination filter would be
activated again later because of frame_wanted_out on its own
outputs, but not sinks.
avfilter_graph_request_oldest() is doing the work of the sink
itself, and is therefore allowed to use frame_blocked_in.
This moves work from the configure to the Make stage where it can
be parallelized and ensures that pkgconfig files are updated when
library versions change.
Bug-Id: 449
This moves work from the configure to the Make stage where it can
be parallelized and ensures that shared libraries are built with
the right version number in the filename.
Configure checks if the ebx register can be used for asm and it has to
be saved if and only if this is not the case.
Without this the build fails when configuring with --toolchain=hardened
--disable-pic on i386 using gcc 4.8:
error: PIC register clobbered by '%ebx' in 'asm'
In that case gcc 4.8 reserves the ebx register for the GOT needed for
PIE, so it can't be used in asm directly.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Calling ff_h264_field_end() when the per-field state is not properly
initialized leads to all kinds of undefined behaviour.
CC: libav-stable@libav.org
Bug-Id: 977 978 992
For field picture, the first_field is set based on its previous value.
Before this commit, first_field is set when reading the picture
coding extension. However, in corrupted files there may be multiple
picture coding extension headers, so the final value of first_field that
is actually used during decoding can be wrong. That can lead to various
undefined behaviour, like predicting from a non-existing field.
Fix this problem, by setting first_field in mpeg_field_start(), which
should be called exactly once per field.
CC: libav-stable@libav.org
Bug-ID: 999
When the input string is too large, so the second condition in if ()
fails, the code will erroneously execute the else branch, indexing the
mac_to_unicode table with a negative index.
CC: libav-stable@libav.org
Bug-Id: 1000
Found-By: Kamil Frankowicz
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).
It should only be set after the decoder state has been fully initialized
for using that SPS.
Fixes possible invalid reads on get_format() failure.
CC: libav-stable@libav.org
A lot of changes happen at the same time:
- Add a framequeue fifo to AVFilterLink.
- split AVFilterLink.status into status_in and status_out: requires
changes to the few filters and programs that use it directly
(f_interleave, split, filtfmts).
- Add a field ready to AVFilterContext, marking when the filter is ready
and its activation priority.
- Add flags to mark blocked links.
- Change ff_filter_frame() to enqueue the frame.
- Change all filtering functions to update the ready field and the
blocked flags.
- Update ff_filter_graph_run_once() to use the ready field.
- buffersrc: always push the frame immediately.
This makes it possible to decode motion jpeg 2000
encoded in a transport stream without a correct PMT/PAT.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The assumption that avcodec_send_packet makes regarding decoders
consuming the entire packet is not true if the codec supports
truncated decoding mode and the truncated flag is turned on.
Steps to reproduce:
./ffmpeg_g -flags truncated \
-i "http://samples.ffmpeg.org/MPEG2/test-ebu-422.40000.pakets.ts" \
-c:v ffv1 -c:a copy -y /tmp/truncated.nut
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Without any optimization flags, MSVC does no dead code elimination (DCE) at
all, even for the most trivial cases. DCE is a prerequisite for building libav
correctly, otherwise there are undefined references to functions for other
architectures and disabled components.
-O1 is the minimal optimization flag for MSVC that does include DCE.
Clang is not able to eliminate the reference to ff_spdif_probe() when
there is a goto target in the same block and optimization is disabled.
This fixes the following build failure on OS X:
./configure --disable-everything --disable-doc \
--enable-decoder=pcm_s16le --enable-demuxer=wav \
--enable-protocol=file --disable-optimizations --cc=clang
make
...
Undefined symbols for architecture x86_64:
"_ff_spdif_probe", referenced from:
_set_spdif in libavformat.a(wavdec.o)
ld: symbol(s) not found for architecture x86_64
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Most decoders return the amount of data used.
This is more consistent
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Most decoders return the amount of data used.
This is more consistent
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Most decoders return the amount of data used.
This is more consistent
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Most decoders return the amount of data used.
This is more consistent
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When receiving fragmented packets, the first packet declares the size,
and the later ones normally are small follow-on packets that don't repeat
the size and the other header fields. But technically, the later fragments
also can have a full header, declaring a different size than the previous
packet.
If the follow-on packet declares a larger size than the initial one, we
could end up writing outside of the allocation.
This fixes out of bounds writes.
Found-by: Paul Cher <paulcher@icloud.com>
Reviewed-by: Paul Cher <paulcher@icloud.com>
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
This seems to have been added by mistake in 11de006b, by not
noticing the negation for the existing condition. This block does
not contain any code that accesses the codec field in AVStream.
This function is meant to serve as a complement to compute_pkt_fields2,
which is guarded by FF_API_COMPUTE_PKT_FIELDS2 && FF_API_LAVF_AVCTX.
Signed-off-by: Martin Storsjö <martin@martin.st>
MPEG Audio frame header must be 4 bytes. If we fail to read
4 bytes bail early to avoid Use-of-uninitialized-value msan error.
Reference https://crbug.com/666874.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The former is not an official pseudo instruction although gas and llvm's
internal assembler support it. Fixes a build error with xcode 6.2
reported by Memphiz on github.
Height of canvas produced by drawtext varies depending on symbols in
text, so add example for printing separate texts aligned horizontally.
Wording suggested by Lou Logan <lou@lrcd.com>
Signed-off-by: Andrey Utkin <andrey.utkin@pb.com>
Signed-off-by: Lou Logan <lou@lrcd.com>
This improves commit 59c7022740.
In ff_thread_report_progress(), the fast code path can load
progress[field] with the relaxed memory order, and the slow code path
can store progress[field] with the release memory order. These changes
are mainly intended to avoid confusion when one inspects the source code.
They are unlikely to have measurable performance improvement.
ff_thread_report_progress() and ff_thread_await_progress() form a pair.
ff_thread_await_progress() reads progress[field] with the acquire memory
order (in the fast code path). Therefore, one expects to see
ff_thread_report_progress() write progress[field] with the matching
release memory order.
In the fast code path in ff_thread_report_progress(), the atomic load of
progress[field] doesn't need the acquire memory order because the
calling thread is trying to make the data it just decoded visible to the
other threads, rather than trying to read the data decoded by other
threads.
In ff_thread_get_buffer(), initialize progress[0] and progress[1] using
atomic_init().
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
It is more natural for this codec and allows to avoid awkward constructs
like "consuming 0 bytes from input". Also, keep a reference to the input
packet to avoid unnecessary copying.
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.
It is useful for testing/debugging and will also be used as the default
filter in the following commit adding pre-decode filtering to avoid
having a separate non-filtered codepath.
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>
integrate it inside multiple_resample
allow some calculations to be performed outside loop
Suggested-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
-pie was added to C flags for ThreadSanitizer in commit
19f251a288. Under clang 3.8.0, the -pie
flag causes a compiler warning and a linker error when running configure
--toolchain=clang-tsan. Here is an excerpt from config.log:
clang ... -fsanitize=thread -pie -std=c11 -fomit-frame-pointer -pthread -c -o /tmp/ffconf.hL61stP9.o /tmp/ffconf.YO6ZaSFG.c
clang: warning: argument unused during compilation: '-pie'
clang -fsanitize=thread -pie -Wl,--as-needed -Wl,-z,noexecstack -o /tmp/ffconf.W5c2e41l /tmp/ffconf.hL61stP9.o -lbz2 -pthread
/usr/bin/ld: /tmp/ffconf.hL61stP9.o: relocation R_X86_64_PC32 against undefined symbol `atan2f@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)
To be conservative, I changed -pie to -fPIE. But the documentation seems
to imply just -fsanitize=thread is enough:
http://clang.llvm.org/docs/ThreadSanitizer.htmlhttps://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Make the one-time initialization in av_get_cpu_flags() thread-safe. The
static variable |cpu_flags| in libavutil/cpu.c is read and written using
normal load and store operations. These are considered as data races.
The fix is to use atomic load and store operations.
The fix can be verified by running the libavutil/tests/cpu_init.c test
program under ThreadSanitizer:
./configure --toolchain=clang-tsan
make libavutil/tests/cpu_init
libavutil/tests/cpu_init
There should be no warnings from ThreadSanitizer.
Co-author: Dmitry Vyukov of Google, who suggested the data race fix.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The demuxer doesn't fill the defaults if the master isn't present.
This results in codecpar->color_space being set with a value of
zero (RGB) on such files.
Signed-off-by: James Almer <jamrial@gmail.com>
As I used simple RGBA formats for subtitles and for the video texture if
avfilter is disabled I kind of assumed that sws_scale won't access data
pointers and strides above index 0, but apparently that is not the case.
Fixes Coverity CID 1396737, 1396738, 1396739, 1396740.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>
And only enable them, if they haven't been disabled.
This is needed for the following patch.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
ff_parse_close expects priv_data to be the ParseContext directly and
thus doesn't work if it isn't at the beginning of OpusParseContext.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Make ff_opus_parse_extradata free allocated memory on error instead of
expecting callers to free it in that case.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Since the default in the libav fork is to only allow known layouts, making
unknown layouts allowed by default here can be a security risk for filters
directly merged from libav. However, usually it is simple to detect such cases,
use of av_get_channel_layout_nb_channels is a good indicator, so I suggest we
change this regardless.
See http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203204.html.
This patch indirectly adds unknown channel layout support for filters where
query_formats is not specified:
abench
afifo
ainterleave
anullsink
apad
aperms
arealtime
aselect
asendcmd
asetnsamples
asetpts
asettb
ashowinfo
azmq
It introduces a query_formats callback for the asyncts filter, which only
supports known channel layouts since it is using libavresample.
And it removes .query_formats callback from filters where it was only there to
support unknown layouts, as this is now the default:
aloop
ametadata
anull
asidedata
asplit
atrim
Acked-by: Nicolas George <george@nsup.org>
Signed-off-by: Marton Balint <cus@passwd.hu>
This decreases the amount of computations and memory needed for analysing mpeg1/2 streams
the properties update is moved from code that is skiped if skip_frame is set
to code that is not skiped so the change doesnt loose that
from being executed
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is faster 2871 -> 2189 cycles for int16 matrixbench -> 23456hz
Fixes a integer overflow in a artificial corner case
Fixes part of 668007-media
Found-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We are checking during encoding if there is enough space as version 4 needs that
check.
Fixes Ticket6005
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Examples use the native FFmpeg AAC encoder but it is no longer
considered experimental and therefore not required.
Signed-off-by: Lou Logan <lou@lrcd.com>
The Solaris and Windows emulations of atomic_compare_exchange_strong()
need typecasts to avoid compiler warnings, because the functions they
call expect a void* pointer but an intptr_t integer is passed.
Note that the emulations of atomic_compare_exchange_strong() (except
the gcc version) only work for atomic_intptr_t because of the type of
the second argument (|expected|). See
http://en.cppreference.com/w/c/atomic:
_Bool atomic_compare_exchange_strong( volatile A* obj,
C* expected, C desired );
The types of the first argument and second argument are different
(|A| and |C|, respectively). |C| is the non-atomic type corresponding
to |A|. In the emulations of atomic_compare_exchange_strong(), |C| is
intptr_t. This implies |A| can only be sig_intptr_t.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Make the one-time initialization in av_get_cpu_flags() thread-safe. The
static variables |flags|, |cpuflags_mask|, and |checked| in
libavutil/cpu.c are read and written using normal load and store
operations. These are considered as data races. The fix is to use atomic
load and store operations.
Remove the |checked| variable because the invalid value of -1 for
|flags| can be used to indicate the same condition. Rename |flags| to
|cpu_flags| and move it to file scope.
The fix can be verified by running the libavutil/tests/cpu_init.c test
program under ThreadSanitizer:
./configure --toolchain=clang-tsan
make libavutil/tests/cpu_init
libavutil/tests/cpu_init
There should be no warnings from ThreadSanitizer.
Co-author: Dmitry Vyukov of Google, who suggested the data race fix.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 6a62795d40)
Cherry pick Suggested-by: Martin Storsjö
This should fix the build failure on macosx
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This implements Spherical Video V1 and V2, as described in the
spatial-media collection by Google.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
While no decoder currently exports spherical information, this type
represents a frame property that has to be passed through from container
to frames.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This implements Spherical Video V1 and V2, as described in the
spatial-media collection by Google.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
While no decoder currently exports spherical information, this type
represents a frame property that has to be passed through from container
to frames.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Fill it with AVStereo3D and AVDisplayMatrix documentation.
Apply the necessary changes to make verbatim code look good in doxygen.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
-pie was added to C flags for ThreadSanitizer in commit
19f251a288. Under clang 3.8.0, the -pie
flag causes a compiler warning and a linker error when running configure
--toolchain=clang-tsan. Here is an excerpt from config.log:
clang ... -fsanitize=thread -pie -std=c11 -fomit-frame-pointer -pthread -c -o /tmp/ffconf.A8SsaoCF.o /tmp/ffconf.JdpujQlD.c
clang: warning: argument unused during compilation: '-pie'
clang -fsanitize=thread -pie -Wl,--as-needed -o /tmp/ffconf.2iYA4bsw /tmp/ffconf.A8SsaoCF.o -lm -lm -lbz2 -lz -pthread
/usr/bin/ld: /tmp/ffconf.A8SsaoCF.o: relocation R_X86_64_PC32 against undefined symbol `atan2f@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)
To be conservative, I changed -pie to -fPIE. But the documentation seems
to imply just -fsanitize=thread is enough:
http://clang.llvm.org/docs/ThreadSanitizer.htmlhttps://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
av_find_stream_info() was deprecated by avformat_find_stream_info(),
correct the warning message in the avformat_find_stream_info() and
comments in the avformat.h
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Handle extralibs in the standard way, add missing pthreads dependency.
Also globally check for -fobj-arc with Objective-C compilers since
that option is useful for other Objective-C code as well.
This is a bit messy as codecar does not support AVOptions so we need
to use AVCodecContext where AVOptions are required and copy back and forth.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Supporting the system was a nice joke for the 9 release, but it has
run its course. Nowadays Plan 9 receives no testing and has no
practical usefulness.
The speex specification does not seem to restrict these values, thus
the limits where choosen so as to avoid multiplicative overflow
Fixes undefined behavior
Fixes: 635422.ogg
Found-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This would be simpler if codecpar supported AVOptions
modern ffserver should be unaffected by this, older ffserver which required the
muxer to directly access the encoder could have issues with this, but this
direct access is just wrong and unsafe
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This accesses the private encoder context, it should not be used by
the current ffserver it may affect old ffserver versions but i believe
there is consens that accessing the private encoder context from the muxer
is completely wrong.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Note, this temporarly drops the ability to set ffmpeg encoder debug and flags2 via ffserver.conf
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is how we initialize refcount in libavutil/buffer.c.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This reverts parts of c16582579b. The hard
coded 30 seconds are a lot, and finishing the seek can takes several
seconds when the source is on a network share. Remove this code
entirely, because it does more bad than good.
(Commit message provided by committer, based on the original messages
by the patch author.)
Signed-off-by: Rainer Hochecker <fernetmenta@online.de>
Signed-off-by: wm4 <nfxjfg@googlemail.com>
This work is sponsored by, and copyright, Google.
Previously all subpartitions except the eob=1 (DC) case ran with
the same runtime:
vp9_inv_dct_dct_16x16_sub16_add_neon: 1373.2
vp9_inv_dct_dct_32x32_sub32_add_neon: 8089.0
By skipping individual 8x16 or 8x32 pixel slices in the first pass,
we reduce the runtime of these functions like this:
vp9_inv_dct_dct_16x16_sub1_add_neon: 235.3
vp9_inv_dct_dct_16x16_sub2_add_neon: 1036.7
vp9_inv_dct_dct_16x16_sub4_add_neon: 1036.7
vp9_inv_dct_dct_16x16_sub8_add_neon: 1036.7
vp9_inv_dct_dct_16x16_sub12_add_neon: 1372.1
vp9_inv_dct_dct_16x16_sub16_add_neon: 1372.1
vp9_inv_dct_dct_32x32_sub1_add_neon: 555.1
vp9_inv_dct_dct_32x32_sub2_add_neon: 5190.2
vp9_inv_dct_dct_32x32_sub4_add_neon: 5180.0
vp9_inv_dct_dct_32x32_sub8_add_neon: 5183.1
vp9_inv_dct_dct_32x32_sub12_add_neon: 6161.5
vp9_inv_dct_dct_32x32_sub16_add_neon: 6155.5
vp9_inv_dct_dct_32x32_sub20_add_neon: 7136.3
vp9_inv_dct_dct_32x32_sub24_add_neon: 7128.4
vp9_inv_dct_dct_32x32_sub28_add_neon: 8098.9
vp9_inv_dct_dct_32x32_sub32_add_neon: 8098.8
I.e. in general a very minor overhead for the full subpartition case due
to the additional cmps, but a significant speedup for the cases when we
only need to process a small part of the actual input data.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
Previously all subpartitions except the eob=1 (DC) case ran with
the same runtime:
Cortex A7 A8 A9 A53
vp9_inv_dct_dct_16x16_sub16_add_neon: 3188.1 2435.4 2499.0 1969.0
vp9_inv_dct_dct_32x32_sub32_add_neon: 18531.7 16582.3 14207.6 12000.3
By skipping individual 4x16 or 4x32 pixel slices in the first pass,
we reduce the runtime of these functions like this:
vp9_inv_dct_dct_16x16_sub1_add_neon: 274.6 189.5 211.7 235.8
vp9_inv_dct_dct_16x16_sub2_add_neon: 2064.0 1534.8 1719.4 1248.7
vp9_inv_dct_dct_16x16_sub4_add_neon: 2135.0 1477.2 1736.3 1249.5
vp9_inv_dct_dct_16x16_sub8_add_neon: 2446.7 1828.7 1993.6 1494.7
vp9_inv_dct_dct_16x16_sub12_add_neon: 2832.4 2118.3 2266.5 1735.1
vp9_inv_dct_dct_16x16_sub16_add_neon: 3211.7 2475.3 2523.5 1983.1
vp9_inv_dct_dct_32x32_sub1_add_neon: 756.2 456.7 862.0 553.9
vp9_inv_dct_dct_32x32_sub2_add_neon: 10682.2 8190.4 8539.2 6762.5
vp9_inv_dct_dct_32x32_sub4_add_neon: 10813.5 8014.9 8518.3 6762.8
vp9_inv_dct_dct_32x32_sub8_add_neon: 11859.6 9313.0 9347.4 7514.5
vp9_inv_dct_dct_32x32_sub12_add_neon: 12946.6 10752.4 10192.2 8280.2
vp9_inv_dct_dct_32x32_sub16_add_neon: 14074.6 11946.5 11001.4 9008.6
vp9_inv_dct_dct_32x32_sub20_add_neon: 15269.9 13662.7 11816.1 9762.6
vp9_inv_dct_dct_32x32_sub24_add_neon: 16327.9 14940.1 12626.7 10516.0
vp9_inv_dct_dct_32x32_sub28_add_neon: 17462.7 15776.1 13446.2 11264.7
vp9_inv_dct_dct_32x32_sub32_add_neon: 18575.5 17157.0 14249.3 12015.1
I.e. in general a very minor overhead for the full subpartition case due
to the additional loads and cmps, but a significant speedup for the cases
when we only need to process a small part of the actual input data.
In common VP9 content in a few inspected clips, 70-90% of the non-dc-only
16x16 and 32x32 IDCTs only have nonzero coefficients in the upper left
8x8 or 16x16 subpartitions respectively.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids reloading them if they haven't been clobbered, if the
first pass also was idct.
This is similar to what was done in the aarch64 version.
Signed-off-by: Martin Storsjö <martin@martin.st>
It randomly causes failures with an error like:
"Failed to set value '-f' for option 'd': Error number -920332800 occurred"
(The error number is different every time.)
Reviewed-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This matrix needs to be applied after all others have (currently only
display matrix from trak), but cannot be handled in movie box, since
streams are not allocated yet. So store it in main context, and apply
it when appropriate, that is after parsing the tkhd one.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
When input surfaces are cuda frames, we will not know what the actual
underlying format (nv12, p010, etc) is at surface allocation time.
On the other hand, we will know when the input frames are actually
registered and associated with a surface.
So, let's delay format discovery until registration time, which is
actually how we handle other frame properties, such as dimensions.
By itself, this change doesn't allow for transcoding of 10bit
content from cuvid, but it reduces the problem to the hardcoding of
the sw format in ffmpeg_cuvid.c
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Using the decode interrupt feature of ffmpeg may cause crashes by
accessing previously freed pointers in matroska_read_close.
To prevent this reset nb_elem to zero after freeing the elements,
because ffmpeg normally tests for nb_elem.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The code calls av_new_packet a few lines above and the allocated memory
has to be freed in case of an error.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The delta escape (2) is supposed to work the same in 4-bit RLE as in
8-bit RLE. This is documented in the MSDN Bitmap Compression page:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx
The unchecked modification of line is safe, since the loop condition
(line >= 0) will check it before any pixel data is written.
Fixes ticket #5153 (output now matches ImageMagick for the provided sample).
Signed-off-by: Daniel Verkamp <daniel@drv.nu>
This fixes a heap-buffer-overflow in ff_er_frame_end when decoding mss2
with coded_width/coded_height larger than width/height.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This fixes some differences between runs of the ffserver tests
(in my local tree 2 runs gave the same result with this but i had other
changes too)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes a segmentation fault caused by calling memcpy with NULL as
second argument in handle_p_frame_apng.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This should not be needed, our AVParsers should do this
I do not have a testcase though, please help testing this and please
add fate tests if you can.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes null pointer dereference
Testcase is simply a ffmpeg instance sending a stream to ffserver while another ffmpeg reads from it
This reverts commit 6f0a1710d7.
Since this is a C11 feature, it requires -std=c11.
Not actually used for anything yet, that will be added in the following
commits.
This merges libav commit 13f5d2bf75.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
mythtv have problem with non-seekable dont write duration and filesize
and there have problem with some other server and player with 0 value
duation and filesize.
So add a flv flags to fix the ticket and make a choose for users.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
give very bad quality for soxr resampler.
linear_interp is intended for using linear interpolation
between filter bank so quality will be better.
i guess this is misunderstood as 'do not use filter bank,
but directly interpolate linearly between samples'.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
This fixes a heap-buffer-overflow in ff_er_frame_end when decoding mss2
with coded_width/coded_height larger than width/height.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This dubious behaviour in nvenc was finally removed by nvidia, and
as we refuse to run on anything older than 7.0, we don't need to
keep it around for old versions.
floats are not necessarily normalized, so a normalized softfloat needs
MIN_EXP lowered by 23 to cover that range.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Otherwise the codec context and codecpar might disagree on the codec id,
triggering asserts in av_parser_parse2.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
separate dsp.resample to dsp.resample_common and dsp.resample_linear
and choose to call faster resample_common even when linear_interp=on
when c->frac and c->dst_incr_mod are both zero
speed up resampling when exact_rational and linear_interp are both
enabled because exact_rational force c->frac and c->dst_incr_mod to
be zero when soft compensation does not happen
benchmark on exact_rational=on:linear_interp=on
old new
real 8.432s 5.097s
user 7.679s 4.989s
sys 0.125s 0.107s
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
Fixes make checkheaders on systems without the Cuda Toolkit, which
was broken after the dynlink changes.
Signed-off-by: James Almer <jamrial@gmail.com>
Move global thread variables to better place.
Use correct variable for simple and complex filtergraphs.
This makes number of threads set per filter work again.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The rtmpdh code can use crypto libraries which may require
a process global init. (gcrypt is one of the libraries
where the rtmpdh test code can fail if global init hasn't been
done, depending on gcrypt version.)
Signed-off-by: Martin Storsjö <martin@martin.st>
Expands the parser to also accept the separator '-' in addition to
'+', and take the negative sign into consideration.
The optional sign for the first factor in the expression is already
covered by parsing for an integer.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Since the same parameter is used for both input and output,
the name inout is more fitting.
This matches the naming used below in the dmbutterfly macro.
Signed-off-by: Martin Storsjö <martin@martin.st>
This reverts commit 81d7f0bbca.
Instead of just benchmarking dc separately, test all relevant subparts
(in the next commit).
Signed-off-by: Martin Storsjö <martin@martin.st>
scaling list is already transfered to raster scan during head parsing,
so no need to transfer it again.
And after this fix, FATE test SLIST_A_Sony_4/SLIST_B_Sony_8/
SLIST_C_Sony_3/SLIST_D_Sony_9 will pass in i965/Skylake.
Signed-off-by: Wang, Yi A <yi.a.wamg@intel.com>
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
Remove the |checked| variable because the invalid value of -1 for
|flags| can be used to indicate the same condition. Also rename |flags|
to |cpu_flags| because there are a local variable and a function
parameter named |flags| in the same file.
Co-author: Dmitry Vyukov of Google
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I moved this into the handle_video_sequence callback because that's
the earliest time you can make an accurate decision as to what the
format should be.
However, transcoding requires that the decision between using
the accelerated PIX_FMT_CUDA vs a normal pix format happen at init()
time. There is enough information available to make that decision
and things work out with the underlying format only being discovered
in the sequence callback.
Functionally similar to av_packet_add_side_data(). Allows the use of an
already allocated buffer as stream side data.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
If makeopts_fate is set, these makeopts are used for running the
tests instead of the normal makeopts. If it isn't set, the normal
makeopts variable is used as before.
This is useful if remote testing on a lesser machine where a large
number of parallel jobs might be undesireable, while wanting to speed
up the build with many parallel processes.
Signed-off-by: Martin Storsjö <martin@martin.st>
If realloc fails, the pointer is overwritten and the previously allocated buffer
is leaked, which goes against the expected functionality of keeping the packet
unchanged in case of error.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
libavcodec/dvbsubdec.c:145:5: warning: ignoring return value of ‘system’, declared with attribute warn_unused_result [-Wunused-result]
libavcodec/dvbsubdec.c:148:5: warning: ignoring return value of ‘system’, declared with attribute warn_unused_result [-Wunused-result]
This patch moves the av_frame_make_writable() call from fill_yuv_image
to get_video_frame so that its argument can be the actual frame that
will be sent to the encoder.
This fixes data corruption issues in codecs that keep references on
one or several previous frames.
Signed-off-by: Sam Hocevar <sam@hocevar.net>
Reviewed-by: wm4
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Requested-by: wm4 ([FFmpeg-devel] [PATCH] avutil/opt: Support max > INT64_MAX in write_number() with AV_OPT_TYPE_INT64)
Requested-by: ronald ([FFmpeg-devel] [PATCH] avutil/opt: Support max > INT64_MAX in write_number() with AV_OPT_TYPE_INT64)
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The nvidia 375.xx driver introduces support for P016 output surfaces,
for 10bit and 12bit HEVC content (it's also the first driver to support
hardware decoding of 12bit content).
The cuvid api, as far as I can tell, only declares one output format
that they appear to refer to as P016 in the driver strings. Of course,
10bit content in P016 is identical to P010, and it is useful for
compatibility purposes to declare the format to be P010 to work with
other components that only know how to consume P010 (and to avoid
triggering swscale conversions that are lossy when they shouldn't be).
For simplicity, this change does not maintain the previous ability
to output dithered NV12 for 10/12 bit input video - the user will need
to update their driver to decode such videos.
P016 is the 16-bit variant of NV12 (planar luma, packed chroma), using
two bytes per component.
It may, and in fact is most likely to, be used in situations where
there are less than 16 bits of data. It is the responsibility of
the writer to zero out any unused LSBs.
Currently, it forces IDR frames for both true and false.
Not entirely sure what the original idea behind the tri-state bool
option is.
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
User selectable surfaces are not working correctly, if you set number of
surfaces on cmdline, it will always use minimum 32 or 48 depends on
selected resolution, but in nvenc it is not necessary to use so many
surfaces.
So from now you can define as low as 1 surface and nvenc will still
work, it will ofcourse lower GPU memory usage by 95% and async_delay to zero
That was the easy part, now littlebit more...
Next part of this patch is to always prefer rc_lookahead to be more
important for number of surfaces, than user defined surfaces value.
Maximum rc_lookahead from nvidia documentation is 32, but could increase
in future generations so there is no limit for this yet. Value
async_depth is still accepted and prefered over rc_lookahead.
There were also bug when you request more than rc_lookahead > 31, it
will always set maximum 31, because surface numbers recalculation was
after setting lookahead, which is now fixed.
Results:
If you set -rc_lookahead 32 and -bf 3 it will now use only 40 surfaces
and lower GPU memory usage by 20%, also it will now increase PSNR by 0.012dB
Two more comments:
1. from my internal test, i don't understand addition of 4 more surfaces
when lookahead is calculated, i didn't used this and everything works as
with those 4 more extra surfaces, does anybody know what is going on
there? I looks like it was used for B frames which are calculated
separately, because B frames maximum is 4.
2. rc_lookahead is defined default to -1, but in test condition if
(ctx->rc_lookahead) which sets lookahead it will be always true, i don't
know if this is intended behavior, so in default behavior is lookahead
always on!
This is default condition when rc_lokkahead is -1 (not defined on
cmdline), whis is maybe something that is not intended:
ctx->encode_config.rcParams.enableLookahead = 1;
ctx->encode_config.rcParams.lookaheadDepth = 0;
ctx->encode_config.rcParams.disableIadapt = 0;
ctx->encode_config.rcParams.disableBadapt = 0;
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
when meeting IDR frame, vaapi_encode_h264 poc number don't reset, now fix
this issue based on h264 spec. Some decoder don't care this case, but this
fix will enhance the encoder action. Before this fix, poc number is
negative in some case.
Reviewed-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Wang, Yi A <yi.a.wang@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
This was not observed earlier because the only syntax element which
it normally misses with the current setup is slice_qp_delta, but that
is always going to be zero (in IDR frames QP isn't varied on the
slice) which will always exp-golomb code as a single 1 bit. The
immediately following part is the byte alignment, which is always a 1
bit followed by 0s which are ignored, so as long as the bitstream is
never aligned at that point we will never notice because the only
difference is that an ignored bit is a 1 instead of a 0.
(cherry picked from commit fc30a90898)
While outwardly bizarre, this change makes the behaviour consistent
with other VAAPI encoders which sync to the encode /input/ picture in
order to wait for /output/ from the encoder. It is not harmful on
i965 (because synchronisation already happens in vaRenderPicture(),
so it has no effect there), and it allows the encoder to work on
mesa/gallium which assumes this behaviour.
(cherry picked from commit 086e4b58b5)
This allows better checking of capabilities and will make it easier
to add more functionality later.
It also commonises some duplicated code around rate control setup
and adds more comments explaining the internals.
(cherry picked from commit 80a5d05108)
There should be an extra offset of 6 on bit_rate_scale and of 4 on
cpb_size_scale which were not accounted for here.
(cherry picked from commit 3a9662af6c)
FLAC streams originating from the FLAC encoder send updated and more
complete STREAMINFO metadata as part of the last packet, so write that
to CodecPrivate instead of the incomplete one available in extradata
during init.
Signed-off-by: James Almer <jamrial@gmail.com>
A negative extradata size for example gets passed to memcpy in
avcodec_parameters_from_context causing a segmentation fault.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
If realloc fails, the pointer is overwritten and the previously allocated
buffer is leaked, which goes against the expected behavior of keeping the
packet unchanged in case of error.
Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This makes av_stream_add_side_data() consistent with av_packet_add_side_data().
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Functionally similar to av_packet_add_side_data(). Allows the use of an
already allocated buffer as stream side data.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
when parsing keyframe index metadata, list the message by trace log
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The clobbering tests in checkasm are only invoked when testing
correctness, so this bug didn't show up when benchmarking the
dc-only version.
Signed-off-by: Martin Storsjö <martin@martin.st>
This reverts commit e0c6b32046.
Said commit changed the behavior of the demuxer and decoder in a non
backwards compatible way.
Demuxers should make extradata available at init if possible, and send
new extradata as side data within a packet if needed.
A better fix for the remuxing crash will follow.
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '8d07e941b04d63fc4443dd986e3dc7b69cdcca43':
FATE: add a test of H.264 SEI recovery in an intra refresh stream
Our H264 decoder drops 3 frames from the beginning of the stream, but
all frames after those match, hence the difference in the fate test.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '46278ec90ac5ad1dab5e85991f176afe49003fee':
mp3enc: write trailing padding
Noop, we have our own implementation for mp3 gapless.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'd60c2d5216930ef98c7d4d6837d6229b37e0dcb3':
mp3dec: read the initial/trailing padding from the LAME tag
Noop, we have our own implementation for mp3 gapless tags.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '2d097c16b833c532ac974a7f1fd05c0a1f3b7675':
libopenh264enc: Return a more sensible error code in some init failure paths
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '36b380dcd52ef47d7ba0559ed51192c88d82a9bd':
libopenh264dec: Simplify the init thanks to FF_CODEC_CAP_INIT_CLEANUP being set
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'd0b1e6049b06eeeeca146ece4d2f199c5dba1565':
libopenh264dec: Fix cleanup if the init failed early
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Just the presence of a hw frames context is not enough to detect whether
the transfer is an upload or a download, because hw frames mapped to
system memory will have a hw frames context attached.
D3DLOCK_READONLY properly corresponds to the absence of the write flag,
not to the presence of the read flag, while D3DLOCK_DISCARD is
equivalent to the overwrite flag.
Fixes division by 0
This is similar to how avg_frame_rate is checked elsewhere
Fixes: 6d24add0455f41b1b45b7ba615cd46f3/asan_generic_dc34c3_5480_0a2ef411cae999b9871ed71a2e481b71.mov
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This matches the other branch
Fixes out of array read
Fixes: 4d142ca76d39fe685effcf5017098723/asan_heap-oob_31ae824_8611_348fdb64f9009b63c8a8eae9a0e497c5.mkv
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '61bd0ed781b56eea1e8e851aab34a2ee3b59fbac':
h264: Log more information about invalid NALu size
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '80fbb7becae530167373fe5178966b7d7604306e':
checkasm: vp8.mc: initialize the full src buffer after ec32574209
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '17c99b6158f2c6720af74e81ee727ee50d2e7e96':
h2645_parse: handle embedded Annex B NAL units in size prefixed NAL units
This commit is a noop, see a9bb4cf87d
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'a8cbe5a0ccebf60a8a8b0aba5d5716dd54c1595c':
h264_ps: export actual height in MBs as SPS.mb_height
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '99cf943339a2e5171863c48cd1a73dd43dc243e1':
d3d11va: don't keep the context lock while waiting for a frame
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '2866d108c9e9da7baf53ff57a51d470691049a57':
vp8dsp: Remove the comment saying that the height is equal to the width
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '8c816c0c9b12fdefd9046415e97df299880bc9b8':
checkasm/arm: align the clobber check data properly for ldrd
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'ec32574209f36467ef0d22c21a7e811ba98c15b6':
checkasm: vp8: mc: test unequal width/height for partitions
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'fc5cdc0d5372f5103c71d5dede296734fe71ead2':
doc: escape left brace in texi2pod.pl regex
This commit is a noop, see e43ea1cbb2
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'd825b1a5306576dcd0553b7d0d24a3a46ad92864':
libopenh264: Support building with the 1.6 release
This commit is a noop, see 293676c476
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '4f7723cb3b913c577842a5bb088c804ddacac8df':
movenc: Add an option for skipping writing the mfra/tfra/mfro trailer
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
A number of new pix_fmts* have been added to AviSynth+:
16-bit packed RGB and RGBA
10-, 12-, 14, and 16-bit YUV 4:2:0, 4:2:2, and 4:4:4
8-, 10-, 12-, 14-, and 16-bit Planar RGB
8-, 10-, 12-, 14-, and 16-bit Planar YUVA and Planar RGBA
10-, 12-, 14-, and 16-bit GRAY variants
32-bit floating point Planar YUV(A), Planar RGB(A), and GRAY
*some of which are not currently available pix_fmts here and were
not added to the demuxer due to this
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Stream timebase should be set using avpriv_set_pts_info, otherwise
avctx->pkt_timebase is not correct, leading to A/V desync.
Signed-off-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Stephen Hutchinson <qyot27@gmail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
uint32 need 4 bytes not 1.
Fix decoding when there is half/float and uint32 channel.
This fixes crashes due to pointer corruption caused by invalid writes.
The problem was introduced in commit
03152e74df.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This fixes NULL pointer dereferencing for formats, where frame->data[1]
is not allocated.
The problem was introduced in commit
257fbc3af4.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This prevented the code from correctly exporting the rotation matrix
which caused a few samples to be displayed wrong.
Introduced in ecd2ec69ce.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Fixes building with --disable-everything --enable-shared --enable-dxva2
The hwcontext DXVA2 implementation in avutil needs this library now, instead
of just the ffmpeg program.
The dc-only mode is already checked to work correctly above, but this
allows benchmarking this mode for performance tuning, and allows making
sure that it actually is correctly hooked up.
Signed-off-by: Martin Storsjö <martin@martin.st>
The latter is 1 cycle faster on a cortex-53 and since the operands are
bytewise (or larger) bitmask (impossible to overflow to zero) both are
equivalent.
Since aarch64 has enough free general purpose registers use them to
branch to the appropiate storage code. 1-2 cycles faster for the
functions using loop_filter 8/16, ... on a cortex-a53. Mixed results
(up to 2 cycles faster/slower) on a cortex-a57.
In the latest git commits of libilbc developers removed WebRtc_xxx typedefs.
This commit uses int types instead. It's safe to apply also for previous
versions since WebRtc_Word16 was always a typedef of int16_t and
WebRtc_UWord16 a typedef of uint16_t.
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; thanks to the larger
amount of registers available, we can do the loop filters with
16 pixels at a time. The implementation is fully templated, with
a single macro which can generate versions for both 8 and
16 pixels wide, for both 4, 8 and 16 pixels loop filters
(and the 4/8 mixed versions as well).
For the 8 pixel wide versions, it is pretty close in speed (the
v_4_8 and v_8_8 filters are the best examples of this; the h_4_8
and h_8_8 filters seem to get some gain in the load/transpose/store
part). For the 16 pixels wide ones, we get a speedup of around
1.2-1.4x compared to the 32 bit version.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_loop_filter_h_4_8_neon: 144.0 127.2
vp9_loop_filter_h_8_8_neon: 207.0 182.5
vp9_loop_filter_h_16_8_neon: 415.0 328.7
vp9_loop_filter_h_16_16_neon: 672.0 558.6
vp9_loop_filter_mix2_h_44_16_neon: 302.0 203.5
vp9_loop_filter_mix2_h_48_16_neon: 365.0 305.2
vp9_loop_filter_mix2_h_84_16_neon: 365.0 305.2
vp9_loop_filter_mix2_h_88_16_neon: 376.0 305.2
vp9_loop_filter_mix2_v_44_16_neon: 193.2 128.2
vp9_loop_filter_mix2_v_48_16_neon: 246.7 218.4
vp9_loop_filter_mix2_v_84_16_neon: 248.0 218.5
vp9_loop_filter_mix2_v_88_16_neon: 302.0 218.2
vp9_loop_filter_v_4_8_neon: 89.0 88.7
vp9_loop_filter_v_8_8_neon: 141.0 137.7
vp9_loop_filter_v_16_8_neon: 295.0 272.7
vp9_loop_filter_v_16_16_neon: 546.0 453.7
The speedup vs C code in checkasm tests is around 2-7x, which is
pretty much the same as for the 32 bit version. Even if these functions
are faster than their 32 bit equivalent, the C version that we compare
to also became around 1.3-1.7x faster than the C version in 32 bit.
Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 4-5x.
Examples of runtimes vs C on a Cortex A57 (for a slightly older version
of the patch):
A57 gcc-5.3 neon
loop_filter_h_4_8_neon: 256.6 93.4
loop_filter_h_8_8_neon: 307.3 139.1
loop_filter_h_16_8_neon: 340.1 254.1
loop_filter_h_16_16_neon: 827.0 407.9
loop_filter_mix2_h_44_16_neon: 524.5 155.4
loop_filter_mix2_h_48_16_neon: 644.5 173.3
loop_filter_mix2_h_84_16_neon: 630.5 222.0
loop_filter_mix2_h_88_16_neon: 697.3 222.0
loop_filter_mix2_v_44_16_neon: 598.5 100.6
loop_filter_mix2_v_48_16_neon: 651.5 127.0
loop_filter_mix2_v_84_16_neon: 591.5 167.1
loop_filter_mix2_v_88_16_neon: 855.1 166.7
loop_filter_v_4_8_neon: 271.7 65.3
loop_filter_v_8_8_neon: 312.5 106.9
loop_filter_v_16_8_neon: 473.3 206.5
loop_filter_v_16_16_neon: 976.1 327.8
The speed-up compared to the C functions is 2.5 to 6 and the cortex-a57
is again 30-50% faster than the cortex-a53.
This is an adapted cherry-pick from libav commits
9d2afd1eb8 and
31756abe29.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; thanks to the larger
amount of registers available, we can do the 16x16 and 32x32
transforms in slices 8 pixels wide instead of 4. This gives
a speedup of around 1.4x compared to the 32 bit version.
The fact that aarch64 doesn't have the same d/q register
aliasing makes some of the macros quite a bit simpler as well.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_inv_adst_adst_4x4_add_neon: 90.0 87.7
vp9_inv_adst_adst_8x8_add_neon: 400.0 354.7
vp9_inv_adst_adst_16x16_add_neon: 2526.5 1827.2
vp9_inv_dct_dct_4x4_add_neon: 74.0 72.7
vp9_inv_dct_dct_8x8_add_neon: 271.0 256.7
vp9_inv_dct_dct_16x16_add_neon: 1960.7 1372.7
vp9_inv_dct_dct_32x32_add_neon: 11988.9 8088.3
vp9_inv_wht_wht_4x4_add_neon: 63.0 57.7
The speedup vs C code (2-4x) is smaller than in the 32 bit case,
mostly because the C code ends up significantly faster (around
1.6x faster, with GCC 5.4) when built for aarch64.
Examples of runtimes vs C on a Cortex A57 (for a slightly older version
of the patch):
A57 gcc-5.3 neon
vp9_inv_adst_adst_4x4_add_neon: 152.2 60.0
vp9_inv_adst_adst_8x8_add_neon: 948.2 288.0
vp9_inv_adst_adst_16x16_add_neon: 4830.4 1380.5
vp9_inv_dct_dct_4x4_add_neon: 153.0 58.6
vp9_inv_dct_dct_8x8_add_neon: 789.2 180.2
vp9_inv_dct_dct_16x16_add_neon: 3639.6 917.1
vp9_inv_dct_dct_32x32_add_neon: 20462.1 4985.0
vp9_inv_wht_wht_4x4_add_neon: 91.0 49.8
The asm is around factor 3-4 faster than C on the cortex-a57 and the asm
is around 30-50% faster on the a57 compared to the a53.
This is an adapted cherry-pick from libav commit
3c9546dfaf.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; it is essentially a 1:1
port with no extra added features, but with some hand tuning
(especially for the plain copy/avg functions). The ARM version
isn't very register starved to begin with, so there's not much
to be gained from having more spare registers here - we only
avoid having to clobber callee-saved registers.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_avg4_neon: 27.2 23.7
vp9_avg8_neon: 56.5 54.7
vp9_avg16_neon: 169.9 167.4
vp9_avg32_neon: 585.8 585.2
vp9_avg64_neon: 2460.3 2294.7
vp9_avg_8tap_smooth_4h_neon: 132.7 125.2
vp9_avg_8tap_smooth_4hv_neon: 478.8 442.0
vp9_avg_8tap_smooth_4v_neon: 126.0 93.7
vp9_avg_8tap_smooth_8h_neon: 241.7 234.2
vp9_avg_8tap_smooth_8hv_neon: 690.9 646.5
vp9_avg_8tap_smooth_8v_neon: 245.0 205.5
vp9_avg_8tap_smooth_64h_neon: 11273.2 11280.1
vp9_avg_8tap_smooth_64hv_neon: 22980.6 22184.1
vp9_avg_8tap_smooth_64v_neon: 11549.7 10781.1
vp9_put4_neon: 18.0 17.2
vp9_put8_neon: 40.2 37.7
vp9_put16_neon: 97.4 99.5
vp9_put32_neon/armv8: 346.0 307.4
vp9_put64_neon/armv8: 1319.0 1107.5
vp9_put_8tap_smooth_4h_neon: 126.7 118.2
vp9_put_8tap_smooth_4hv_neon: 465.7 434.0
vp9_put_8tap_smooth_4v_neon: 113.0 86.5
vp9_put_8tap_smooth_8h_neon: 229.7 221.6
vp9_put_8tap_smooth_8hv_neon: 658.9 621.3
vp9_put_8tap_smooth_8v_neon: 215.0 187.5
vp9_put_8tap_smooth_64h_neon: 10636.7 10627.8
vp9_put_8tap_smooth_64hv_neon: 21076.8 21026.9
vp9_put_8tap_smooth_64v_neon: 9635.0 9632.4
These are generally about as fast as the corresponding ARM
routines on the same CPU (at least on the A53), in most cases
marginally faster.
The speedup vs C code is pretty much the same as for the 32 bit
case; on the A53 it's around 6-13x for ther larger 8tap filters.
The exact speedup varies a little, since the C versions generally
don't end up exactly as slow/fast as on 32 bit.
This is an adapted cherry-pick from libav commit
383d96aa22.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
With apple tools, the linker fails with errors like these, if the
offset is negative:
ld: in section __TEXT,__text reloc 8: symbol index out of range for architecture arm64
This is cherry-picked from libav commit
c44a8a3eab.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This work is sponsored by, and copyright, Google.
The implementation tries to have smart handling of cases
where no pixels need the full filtering for the 8/16 width
filters, skipping both calculation and writeback of the
unmodified pixels in those cases. The actual effect of this
is hard to test with checkasm though, since it tests the
full filtering, and the benefit depends on how many filtered
blocks use the shortcut.
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_loop_filter_h_4_8_neon: 2.72 2.68 1.78 3.15
vp9_loop_filter_h_8_8_neon: 2.36 2.38 1.70 2.91
vp9_loop_filter_h_16_8_neon: 1.80 1.89 1.45 2.01
vp9_loop_filter_h_16_16_neon: 2.81 2.78 2.18 3.16
vp9_loop_filter_mix2_h_44_16_neon: 2.65 2.67 1.93 3.05
vp9_loop_filter_mix2_h_48_16_neon: 2.46 2.38 1.81 2.85
vp9_loop_filter_mix2_h_84_16_neon: 2.50 2.41 1.73 2.85
vp9_loop_filter_mix2_h_88_16_neon: 2.77 2.66 1.96 3.23
vp9_loop_filter_mix2_v_44_16_neon: 4.28 4.46 3.22 5.70
vp9_loop_filter_mix2_v_48_16_neon: 3.92 4.00 3.03 5.19
vp9_loop_filter_mix2_v_84_16_neon: 3.97 4.31 2.98 5.33
vp9_loop_filter_mix2_v_88_16_neon: 3.91 4.19 3.06 5.18
vp9_loop_filter_v_4_8_neon: 4.53 4.47 3.31 6.05
vp9_loop_filter_v_8_8_neon: 3.58 3.99 2.92 5.17
vp9_loop_filter_v_16_8_neon: 3.40 3.50 2.81 4.68
vp9_loop_filter_v_16_16_neon: 4.66 4.41 3.74 6.02
The speedup vs C code is around 2-6x. The numbers are quite
inconclusive though, since the checkasm test runs multiple filterings
on top of each other, so later rounds might end up with different
codepaths (different decisions on which filter to apply, based
on input pixel differences). Disabling the early-exit in the asm
doesn't give a fair comparison either though, since the C code
only does the necessary calcuations for each row.
Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 4-9x.
This is pretty similar in runtime to the corresponding routines
in libvpx. (This is comparing vpx_lpf_vertical_16_neon,
vpx_lpf_horizontal_edge_8_neon and vpx_lpf_horizontal_edge_16_neon
to vp9_loop_filter_h_16_8_neon, vp9_loop_filter_v_16_8_neon
and vp9_loop_filter_v_16_16_neon - note that the naming of horizonal
and vertical is flipped between the libraries.)
In order to have stable, comparable numbers, the early exits in both
asm versions were disabled, forcing the full filtering codepath.
Cortex A7 A8 A9 A53
vp9_loop_filter_h_16_8_neon: 597.2 472.0 482.4 415.0
libvpx vpx_lpf_vertical_16_neon: 626.0 464.5 470.7 445.0
vp9_loop_filter_v_16_8_neon: 500.2 422.5 429.7 295.0
libvpx vpx_lpf_horizontal_edge_8_neon: 586.5 414.5 415.6 383.2
vp9_loop_filter_v_16_16_neon: 905.0 784.7 791.5 546.0
libvpx vpx_lpf_horizontal_edge_16_neon: 1060.2 751.7 743.5 685.2
Our version is consistently faster on on A7 and A53, marginally slower on
A8, and sometimes faster, sometimes slower on A9 (marginally slower in all
three tests in this particular test run).
This is an adapted cherry-pick from libav commit
dd299a2d6d.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This work is sponsored by, and copyright, Google.
For the transforms up to 8x8, we can fit all the data (including
temporaries) in registers and just do a straightforward transform
of all the data. For 16x16, we do a transform of 4x16 pixels in
4 slices, using a temporary buffer. For 32x32, we transform 4x32
pixels at a time, in two steps of 4x16 pixels each.
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_inv_adst_adst_4x4_add_neon: 3.39 5.83 4.17 4.01
vp9_inv_adst_adst_8x8_add_neon: 3.79 4.86 4.23 3.98
vp9_inv_adst_adst_16x16_add_neon: 3.33 4.36 4.11 4.16
vp9_inv_dct_dct_4x4_add_neon: 4.06 6.16 4.59 4.46
vp9_inv_dct_dct_8x8_add_neon: 4.61 6.01 4.98 4.86
vp9_inv_dct_dct_16x16_add_neon: 3.35 3.44 3.36 3.79
vp9_inv_dct_dct_32x32_add_neon: 3.89 3.50 3.79 4.42
vp9_inv_wht_wht_4x4_add_neon: 3.22 5.13 3.53 3.77
Thus, the speedup vs C code is around 3-6x.
This is mostly marginally faster than the corresponding routines
in libvpx on most cores, tested with their 32x32 idct (compared to
vpx_idct32x32_1024_add_neon). These numbers are slightly in libvpx's
favour since their version doesn't clear the input buffer like ours
do (although the effect of that on the total runtime probably is
negligible.)
Cortex A7 A8 A9 A53
vp9_inv_dct_dct_32x32_add_neon: 18436.8 16874.1 14235.1 11988.9
libvpx vpx_idct32x32_1024_add_neon 20789.0 13344.3 15049.9 13030.5
Only on the Cortex A8, the libvpx function is faster. On the other cores,
ours is slightly faster even though ours has got source block clearing
integrated.
This is an adapted cherry-pick from libav commits
a67ae67083 and
52d196fb30.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This work is sponsored by, and copyright, Google.
The filter coefficients are signed values, where the product of the
multiplication with one individual filter coefficient doesn't
overflow a 16 bit signed value (the largest filter coefficient is
127). But when the products are accumulated, the resulting sum can
overflow the 16 bit signed range. Instead of accumulating in 32 bit,
we accumulate the largest product (either index 3 or 4) last with a
saturated addition.
(The VP8 MC asm does something similar, but slightly simpler, by
accumulating each half of the filter separately. In the VP9 MC
filters, each half of the filter can also overflow though, so the
largest component has to be handled individually.)
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_avg4_neon: 1.71 1.15 1.42 1.49
vp9_avg8_neon: 2.51 3.63 3.14 2.58
vp9_avg16_neon: 2.95 6.76 3.01 2.84
vp9_avg32_neon: 3.29 6.64 2.85 3.00
vp9_avg64_neon: 3.47 6.67 3.14 2.80
vp9_avg_8tap_smooth_4h_neon: 3.22 4.73 2.76 4.67
vp9_avg_8tap_smooth_4hv_neon: 3.67 4.76 3.28 4.71
vp9_avg_8tap_smooth_4v_neon: 5.52 7.60 4.60 6.31
vp9_avg_8tap_smooth_8h_neon: 6.22 9.04 5.12 9.32
vp9_avg_8tap_smooth_8hv_neon: 6.38 8.21 5.72 8.17
vp9_avg_8tap_smooth_8v_neon: 9.22 12.66 8.15 11.10
vp9_avg_8tap_smooth_64h_neon: 7.02 10.23 5.54 11.58
vp9_avg_8tap_smooth_64hv_neon: 6.76 9.46 5.93 9.40
vp9_avg_8tap_smooth_64v_neon: 10.76 14.13 9.46 13.37
vp9_put4_neon: 1.11 1.47 1.00 1.21
vp9_put8_neon: 1.23 2.17 1.94 1.48
vp9_put16_neon: 1.63 4.02 1.73 1.97
vp9_put32_neon: 1.56 4.92 2.00 1.96
vp9_put64_neon: 2.10 5.28 2.03 2.35
vp9_put_8tap_smooth_4h_neon: 3.11 4.35 2.63 4.35
vp9_put_8tap_smooth_4hv_neon: 3.67 4.69 3.25 4.71
vp9_put_8tap_smooth_4v_neon: 5.45 7.27 4.49 6.52
vp9_put_8tap_smooth_8h_neon: 5.97 8.18 4.81 8.56
vp9_put_8tap_smooth_8hv_neon: 6.39 7.90 5.64 8.15
vp9_put_8tap_smooth_8v_neon: 9.03 11.84 8.07 11.51
vp9_put_8tap_smooth_64h_neon: 6.78 9.48 4.88 10.89
vp9_put_8tap_smooth_64hv_neon: 6.99 8.87 5.94 9.56
vp9_put_8tap_smooth_64v_neon: 10.69 13.30 9.43 14.34
For the larger 8tap filters, the speedup vs C code is around 5-14x.
This is significantly faster than libvpx's implementation of the same
functions, at least when comparing the put_8tap_smooth_64 functions
(compared to vpx_convolve8_horiz_neon and vpx_convolve8_vert_neon from
libvpx).
Absolute runtimes from checkasm:
Cortex A7 A8 A9 A53
vp9_put_8tap_smooth_64h_neon: 20150.3 14489.4 19733.6 10863.7
libvpx vpx_convolve8_horiz_neon: 52623.3 19736.4 21907.7 25027.7
vp9_put_8tap_smooth_64v_neon: 14455.0 12303.9 13746.4 9628.9
libvpx vpx_convolve8_vert_neon: 42090.0 17706.2 17659.9 16941.2
Thus, on the A9, the horizontal filter is only marginally faster than
libvpx, while our version is significantly faster on the other cores,
and the vertical filter is significantly faster on all cores. The
difference is especially large on the A7.
The libvpx implementation does the accumulation in 32 bit, which
probably explains most of the differences.
This is an adapted cherry-pick from libav commits
ffbd1d2b00,
392caa65df,
557c1675cf and
11623217e3.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
We reset .Lpic_gp to zero at the start of each function, which means
that the logic within movrelx for clearing gp when necessary will
be missed.
This fixes using movrelx in different functions with a different
helper register.
This is cherry-picked from libav commit
824e8c2840.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Make them aligned, to allow efficient access to them from simd.
This is an adapted cherry-pick from libav commit
a4cfcddcb0.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Also a small cosmetic change to the avx2 idct16 version to make it
explicit that one of the arguments to the write-out macros is unused
for >=avx2 (it uses pmovzxbw instead of punpcklbw).
libavfilter/af_asyncts.c:212:9: warning: absolute value function 'labs' given an argument of type 'int64_t' (aka 'long long') but has parameter of type 'long' which may cause truncation of value [-Wabsolute-value]
This was correct for H.26[45], because libmfx uses the same values
derived from profile_idc and the constraint_set flags, but it is
wrong for other codecs.
Also avoid passing FF_LEVEL_UNKNOWN (-99) as the level, as this is
certainly invalid.
* commit 'dc08bbf63a217c839aa4c143f2a1d0b7e2e6d997':
vp8dsp: Clarify the first dimension of the mc function tables
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '924e2ecd2b7d51cca60c79351ef16b04dd4245c3':
qsvdec: when a frames ctx is supplied, use its frame dimensions
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '92736c74fb1633e36f7134a880422a9b7db14d3f':
qsvdec: add support for P010 (10-bit 420) decoding
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'ce320cf1c4daab3e2e3726ed7d2e879d10f7b991':
qsvdec: use the same mfxFrameInfo for allocating frames that was passed to DECODE_Init
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '536bb17e9659c5ed7576a218d4085cdd6d5742fa':
qsvdec: make ff_qsv_map_pixfmt() return a MFX fourcc as well
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '4926fa9a4aa03f3b751f52e900b9efb87fea0591':
hwcontext_vaapi: Add driver quirks to the hwdevice
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'e78e5b735fd559bc7aa3f5a01e9c8d37dc2ec6d8':
swscale: add P010 input support
This commit is a noop, see 2e31434d84
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'b7c5f885233a7b8692140c920d9f43220dc830d9':
pixfmt: add P010 pixel format
This commit is a noop, see c2869b4640
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'b55566db4c51d920a6496455bb30a608e5a50a41':
avconv: use avcodec_parameters_copy() with streamcopy
The fate-aac-autobsf-adtstoasc changes from writing an audio bitdepth
based on the sample format, which is now available.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'be3e807c8fad1f82766c083073e44396799f155b':
oggparseopus: export pre-skip
Noop, we already export this information
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '029cf99c5166b36f33381cd8ebfa5f1f1f463d1f':
mov: Save number of stsd elements after stream extradata allocation
Mostly noop, see 8b43ee4054
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '6c445990e64124ad64c79423dfd3764520648c89':
tiffenc: Check zlib support for deflate option during initialization
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'd8f3b0fb584677d4882e3a2d7c28f8b15c7319f5':
targaenc: Move size check to initialization function
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '67cb2c0f73ec08bdcecd675c1ffe25c3a5b26ef2':
checkasm: hevc: Iterate over features first, then over bitdepths
Noop, we don't have these checkasm tests.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'fe27792fd779ac4cdd5e57be5f6f488483c307b2':
build: Move ff_mpeg12_frame_rate_tab to a separate file
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '8c929037ec75fbe9f367e0a31ee34839e92de481':
build: Add a new component for H.264 parsing code
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '3c08b7bc761b6411f55db68189721638dde2c46a':
ffv1: Report additional bitstream information in verbose mode
Noop, we already have bitstream information printing.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'fe6e5cbea7dbd5d2c67d79b5570e26debb70e95b':
ffv1: Remove version 2 and mark version 3 as non-experimental
Noop, our ffv1 decoder is far more advanced and version 3 has been stable for a while.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '7c55fac7dfa8bad9644dea5d03309da30be69563':
fate: Add test for webp
Noop, we already have a variety of webp tests, including a fate-webp target,
which would collide with this test.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
__MAC_10_11 can be present in updated revision of an older SDK so it
can't reliably detect availability of kAudioFormatEnhancedAC3 constant.
Fixes: b4daa2c40f ('lavc/audiotoolboxdec: add eac3 decoder')
Cc: Rodger Combs <rodger.combs@gmail.com>
Signed-off-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
Previous version reviewed by: Rodger Combs <rodger.combs@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; thanks to the larger
amount of registers available, we can do the 16x16 and 32x32
transforms in slices 8 pixels wide instead of 4. This gives
a speedup of around 1.4x compared to the 32 bit version.
The fact that aarch64 doesn't have the same d/q register
aliasing makes some of the macros quite a bit simpler as well.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_inv_adst_adst_4x4_add_neon: 90.0 87.7
vp9_inv_adst_adst_8x8_add_neon: 400.0 354.7
vp9_inv_adst_adst_16x16_add_neon: 2526.5 1827.2
vp9_inv_dct_dct_4x4_add_neon: 74.0 72.7
vp9_inv_dct_dct_8x8_add_neon: 271.0 256.7
vp9_inv_dct_dct_16x16_add_neon: 1960.7 1372.7
vp9_inv_dct_dct_32x32_add_neon: 11988.9 8088.3
vp9_inv_wht_wht_4x4_add_neon: 63.0 57.7
The speedup vs C code (2-4x) is smaller than in the 32 bit case,
mostly because the C code ends up significantly faster (around
1.6x faster, with GCC 5.4) when built for aarch64.
Examples of runtimes vs C on a Cortex A57 (for a slightly older version
of the patch):
A57 gcc-5.3 neon
vp9_inv_adst_adst_4x4_add_neon: 152.2 60.0
vp9_inv_adst_adst_8x8_add_neon: 948.2 288.0
vp9_inv_adst_adst_16x16_add_neon: 4830.4 1380.5
vp9_inv_dct_dct_4x4_add_neon: 153.0 58.6
vp9_inv_dct_dct_8x8_add_neon: 789.2 180.2
vp9_inv_dct_dct_16x16_add_neon: 3639.6 917.1
vp9_inv_dct_dct_32x32_add_neon: 20462.1 4985.0
vp9_inv_wht_wht_4x4_add_neon: 91.0 49.8
The asm is around factor 3-4 faster than C on the cortex-a57 and the asm
is around 30-50% faster on the a57 compared to the a53.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; thanks to the larger
amount of registers available, we can do the loop filters with
16 pixels at a time. The implementation is fully templated, with
a single macro which can generate versions for both 8 and
16 pixels wide, for both 4, 8 and 16 pixels loop filters
(and the 4/8 mixed versions as well).
For the 8 pixel wide versions, it is pretty close in speed (the
v_4_8 and v_8_8 filters are the best examples of this; the h_4_8
and h_8_8 filters seem to get some gain in the load/transpose/store
part). For the 16 pixels wide ones, we get a speedup of around
1.2-1.4x compared to the 32 bit version.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_loop_filter_h_4_8_neon: 144.0 127.2
vp9_loop_filter_h_8_8_neon: 207.0 182.5
vp9_loop_filter_h_16_8_neon: 415.0 328.7
vp9_loop_filter_h_16_16_neon: 672.0 558.6
vp9_loop_filter_mix2_h_44_16_neon: 302.0 203.5
vp9_loop_filter_mix2_h_48_16_neon: 365.0 305.2
vp9_loop_filter_mix2_h_84_16_neon: 365.0 305.2
vp9_loop_filter_mix2_h_88_16_neon: 376.0 305.2
vp9_loop_filter_mix2_v_44_16_neon: 193.2 128.2
vp9_loop_filter_mix2_v_48_16_neon: 246.7 218.4
vp9_loop_filter_mix2_v_84_16_neon: 248.0 218.5
vp9_loop_filter_mix2_v_88_16_neon: 302.0 218.2
vp9_loop_filter_v_4_8_neon: 89.0 88.7
vp9_loop_filter_v_8_8_neon: 141.0 137.7
vp9_loop_filter_v_16_8_neon: 295.0 272.7
vp9_loop_filter_v_16_16_neon: 546.0 453.7
The speedup vs C code in checkasm tests is around 2-7x, which is
pretty much the same as for the 32 bit version. Even if these functions
are faster than their 32 bit equivalent, the C version that we compare
to also became around 1.3-1.7x faster than the C version in 32 bit.
Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 4-5x.
Examples of runtimes vs C on a Cortex A57 (for a slightly older version
of the patch):
A57 gcc-5.3 neon
loop_filter_h_4_8_neon: 256.6 93.4
loop_filter_h_8_8_neon: 307.3 139.1
loop_filter_h_16_8_neon: 340.1 254.1
loop_filter_h_16_16_neon: 827.0 407.9
loop_filter_mix2_h_44_16_neon: 524.5 155.4
loop_filter_mix2_h_48_16_neon: 644.5 173.3
loop_filter_mix2_h_84_16_neon: 630.5 222.0
loop_filter_mix2_h_88_16_neon: 697.3 222.0
loop_filter_mix2_v_44_16_neon: 598.5 100.6
loop_filter_mix2_v_48_16_neon: 651.5 127.0
loop_filter_mix2_v_84_16_neon: 591.5 167.1
loop_filter_mix2_v_88_16_neon: 855.1 166.7
loop_filter_v_4_8_neon: 271.7 65.3
loop_filter_v_8_8_neon: 312.5 106.9
loop_filter_v_16_8_neon: 473.3 206.5
loop_filter_v_16_16_neon: 976.1 327.8
The speed-up compared to the C functions is 2.5 to 6 and the cortex-a57
is again 30-50% faster than the cortex-a53.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'e48746deec48e9ff195841bc3266b4e153a878cd':
checkasm: h264dsp: Move the x and y variables into the randomize_buffer macro
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '82b7525173f20702a8cbc26ebedbf4b69b8fecec':
Add an OpenH264 decoder wrapper
This commit is a noop, see c5d326f551
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '785c25443b56adb6dbbb78d68cccbd9bd4a42e05':
movenc: Apply offsets on timestamps when peeking into interleaving queues
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'eccfb9778ae939764d17457f34338d140832d9e1':
qsvdec_hevc: add the UID of the HEVC HW decoder plugin
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'c3f113d58488df7594a489bdbb993a69ad47063c':
vf_hwdownload: allocate the destination frame for the pool size
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'fdfe01365d579189d9a55b3741dba2ac46eb1df8':
hwcontext: allocate the destination frame for the pool size
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '5fcae3b3f93fd02b3d1e009b9d9b17410fca9498':
hwcontext: clarify the behaviour of transfer_data() for cropped frames
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '94ebf5565849e4dc036d2ca43979571ed3736457':
avconv: restructure sending EOF to filters
Noop, as its a fixup to a previously skipped commit
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'd2e56cf753a6c462041dee897d9d0c90f349988c':
avconv: move flushing the queued frames to configure_filtergraph()
Noop, as its a fixup to a previously skipped commit
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
The Intel binary iHD driver does not support the
VASurfaceAttribMemoryType, so surface allocation will fail when using
it.
(cherry picked from commit 2124711b95)
If no string argument is supplied when av_hwdevice_ctx_create() is
called to create a VAAPI device, we currently only try the default
X11 display (that is, $DISPLAY) to find a device, and will therefore
fail in the absence of an X server to connect to. Change the logic
to also look for a device via the first DRM render node (that is,
"/dev/dri/renderD128"), which is probably the right thing to use in
most simple configurations which only have one DRM device.
(cherry picked from commit 121f34d5f0)
No longer leaks memory when used with a driver with the "render does
not destroy param buffers" quirk (i.e. Intel i965).
(cherry picked from commit 221ffca631)
Fixes ticket #5871.
The driver being used is detected inside av_hwdevice_ctx_init() and
the quirks field then set from a table of known device. If this
behaviour is unwanted, the user can also set the quirks field
manually.
Also adds the Intel i965 driver quirk (it does not destroy parameter
buffers used in a call to vaRenderPicture()) and detects that driver
to set it.
(cherry picked from commit 4926fa9a4a)
Set up the encoder with a hardware context which will match the one
the decoder will use when it starts later.
Includes 02c2761973, with additional
hackery to get around a3a0230a98 being
skipped.
* commit '8a62d2c28fbacd1ae20c35887a1eecba2be14371':
vaapi_encode: Maintain a pool of bitstream output buffers
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '4a081f224e12f4227ae966bcbdd5384f22121ecf':
libavcodec: fix constness in clobber test avcodec_open2() wrappers
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '02c2761973dfc886e94a60a9c7d6d30c296d5b8c':
avconv_qsv: use the device creation API
Not merged, our ffmpeg hwaccel infra is not quite the same as avconvs.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '232399e3ee219d16d0e0d482c9f31a26202d4993':
avconv: pass the hwaccel frames context to the decoder
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'a3a0230a9870b9018dc7415ae5872784d524cfe5':
avconv: init filtergraphs only after we have a frame on each input
This commit is a noop since it doesn't apply cleanly due to differences
in the dataflow between avconv and ffmpeg, and thus fixing this in the
scope of a merge is unfeasible.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '3e265ca58f0505470186dce300ab66a6eac3978e':
avconv: do packet ts rescaling in write_packet()
This commit is a noop since it doesn't apply cleanly due to differences
in the dataflow between avconv and ffmpeg, and thus fixing this in the
scope of a merge is unfeasible.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'ba7397baef796ca3991fe1c921bc91054407c48b':
avconv: factor out initializing stream parameters for encoding
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
The handling of the other block sizes was limited to 'SCALED == 0' in
commit dc96c0f9fc, so this assert should
be disabled, too, as it can now be triggered.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Fixes building for Windows x86 with MSVC using the link libraries distributed with the CUDA SDK.
check_lib2 is required here because it includes the header to get the full signature of the
function, including the stdcall calling convention and all of its arguments, which enables
the linker to determine the fully qualified object name and resolve it through the import
library, since the CUDA SDK libraries do not include un-qualified aliases.
AVFilterLink.frame_count is supposed to count the number of frames
that were passed on the link, but with min_samples, that number is
not always the same for the source and destination filters.
With the addition of a FIFO on the link, the difference will become
more significant.
Split the variable in two: frame_count_in counts the number of
frames that entered the link, frame_count_out counts the number
of frames that were sent to the destination filter.
The test is not supposed to cover audio.
Also, using -vframes along with an audio stream depends on
the exact order the frames are processed by filters, it is
too much constraint to guarantee.
Fixes valgrind warning about "Conditional jump or move depends on uninitialised value(s)"
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
libavcodec/ratecontrol.c:120:9: warning: ISO C forbids initialization between function pointer and ‘void *’ [-Wpedantic]
libavcodec/ratecontrol.c:121:9: warning: ISO C forbids initialization between function pointer and ‘void *’ [-Wpedantic]
Otherwise put_bits can be called with a value that doesn't fit in the
sample_len, causing an assertion failure.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
From 'man ppm': The maximum color value (Maxval), again in ASCII decimal.
Must be less than 65536.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Also contains the following changes to the library:
- add ff_ prefix to functions
- remove cplusplus defines.
- add FF_ prefix to contants and some structs
- remove true peak calculation feature, since it uses its own resampler, and
af_loudnorm does not need it.
- remove version info and some fprintf(stderr) functions
- convert to use av_malloc
- always use histogram mode for LRA calculation, otherwise LRA data is slowly
consuming memory making af_loudnorm unfit for 24/7 operation. It also uses a
BSD style linked list implementation which is probably not available on all
platforms. So let's just remove the classic mode which not uses histogram.
- add ff_thread_once for calculating static histogram tables
- convert some functions to void which cannot fail
- remove intrinsics and some unused headers
- add support for planar audio
- remove channel / sample rate changer function, in ffmpeg usually we simply
alloc a new context
- convert some static variables to defines
- declare static histogram variables as aligned
- convert some initalizations to mallocz
- add window size parameter to init function and remove window size setter
function
- convert return codes to AVERROR
- fix indentation
Signed-off-by: Marton Balint <cus@passwd.hu>
This work is sponsored by, and copyright, Google.
The implementation tries to have smart handling of cases
where no pixels need the full filtering for the 8/16 width
filters, skipping both calculation and writeback of the
unmodified pixels in those cases. The actual effect of this
is hard to test with checkasm though, since it tests the
full filtering, and the benefit depends on how many filtered
blocks use the shortcut.
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_loop_filter_h_4_8_neon: 2.72 2.68 1.78 3.15
vp9_loop_filter_h_8_8_neon: 2.36 2.38 1.70 2.91
vp9_loop_filter_h_16_8_neon: 1.80 1.89 1.45 2.01
vp9_loop_filter_h_16_16_neon: 2.81 2.78 2.18 3.16
vp9_loop_filter_mix2_h_44_16_neon: 2.65 2.67 1.93 3.05
vp9_loop_filter_mix2_h_48_16_neon: 2.46 2.38 1.81 2.85
vp9_loop_filter_mix2_h_84_16_neon: 2.50 2.41 1.73 2.85
vp9_loop_filter_mix2_h_88_16_neon: 2.77 2.66 1.96 3.23
vp9_loop_filter_mix2_v_44_16_neon: 4.28 4.46 3.22 5.70
vp9_loop_filter_mix2_v_48_16_neon: 3.92 4.00 3.03 5.19
vp9_loop_filter_mix2_v_84_16_neon: 3.97 4.31 2.98 5.33
vp9_loop_filter_mix2_v_88_16_neon: 3.91 4.19 3.06 5.18
vp9_loop_filter_v_4_8_neon: 4.53 4.47 3.31 6.05
vp9_loop_filter_v_8_8_neon: 3.58 3.99 2.92 5.17
vp9_loop_filter_v_16_8_neon: 3.40 3.50 2.81 4.68
vp9_loop_filter_v_16_16_neon: 4.66 4.41 3.74 6.02
The speedup vs C code is around 2-6x. The numbers are quite
inconclusive though, since the checkasm test runs multiple filterings
on top of each other, so later rounds might end up with different
codepaths (different decisions on which filter to apply, based
on input pixel differences). Disabling the early-exit in the asm
doesn't give a fair comparison either though, since the C code
only does the necessary calcuations for each row.
Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 4-9x.
This is pretty similar in runtime to the corresponding routines
in libvpx. (This is comparing vpx_lpf_vertical_16_neon,
vpx_lpf_horizontal_edge_8_neon and vpx_lpf_horizontal_edge_16_neon
to vp9_loop_filter_h_16_8_neon, vp9_loop_filter_v_16_8_neon
and vp9_loop_filter_v_16_16_neon - note that the naming of horizonal
and vertical is flipped between the libraries.)
In order to have stable, comparable numbers, the early exits in both
asm versions were disabled, forcing the full filtering codepath.
Cortex A7 A8 A9 A53
vp9_loop_filter_h_16_8_neon: 597.2 472.0 482.4 415.0
libvpx vpx_lpf_vertical_16_neon: 626.0 464.5 470.7 445.0
vp9_loop_filter_v_16_8_neon: 500.2 422.5 429.7 295.0
libvpx vpx_lpf_horizontal_edge_8_neon: 586.5 414.5 415.6 383.2
vp9_loop_filter_v_16_16_neon: 905.0 784.7 791.5 546.0
libvpx vpx_lpf_horizontal_edge_16_neon: 1060.2 751.7 743.5 685.2
Our version is consistently faster on on A7 and A53, marginally slower on
A8, and sometimes faster, sometimes slower on A9 (marginally slower in all
three tests in this particular test run).
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
For the transforms up to 8x8, we can fit all the data (including
temporaries) in registers and just do a straightforward transform
of all the data. For 16x16, we do a transform of 4x16 pixels in
4 slices, using a temporary buffer. For 32x32, we transform 4x32
pixels at a time, in two steps of 4x16 pixels each.
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_inv_adst_adst_4x4_add_neon: 3.39 5.83 4.17 4.01
vp9_inv_adst_adst_8x8_add_neon: 3.79 4.86 4.23 3.98
vp9_inv_adst_adst_16x16_add_neon: 3.33 4.36 4.11 4.16
vp9_inv_dct_dct_4x4_add_neon: 4.06 6.16 4.59 4.46
vp9_inv_dct_dct_8x8_add_neon: 4.61 6.01 4.98 4.86
vp9_inv_dct_dct_16x16_add_neon: 3.35 3.44 3.36 3.79
vp9_inv_dct_dct_32x32_add_neon: 3.89 3.50 3.79 4.42
vp9_inv_wht_wht_4x4_add_neon: 3.22 5.13 3.53 3.77
Thus, the speedup vs C code is around 3-6x.
This is mostly marginally faster than the corresponding routines
in libvpx on most cores, tested with their 32x32 idct (compared to
vpx_idct32x32_1024_add_neon). These numbers are slightly in libvpx's
favour since their version doesn't clear the input buffer like ours
do (although the effect of that on the total runtime probably is
negligible.)
Cortex A7 A8 A9 A53
vp9_inv_dct_dct_32x32_add_neon: 18436.8 16874.1 14235.1 11988.9
libvpx vpx_idct32x32_1024_add_neon 20789.0 13344.3 15049.9 13030.5
Only on the Cortex A8, the libvpx function is faster. On the other cores,
ours is slightly faster even though ours has got source block clearing
integrated.
Signed-off-by: Martin Storsjö <martin@martin.st>
Documents options and behaviour, noting when 'chunks' option will
not be honoured.
Signed-off-by: Tom Butterworth <bangnoise@gmail.com>
Signed-off-by: Martin Vignali <martin.vignali@gmail.com>
It can read less than the requested amount, in which case buf contains
uninitialized data, causing problems like segmentation faults later on.
Also make sure that image->size is positive, so that it can't match a
negative error code.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
When decoding with threads enabled, the get_format callback will be
called with one of the per-thread codec contexts rather than with the
outer context. If a hwaccel is in use too, this will add a reference
to the hardware frames context on that codec context, which will then
propagate to all of the other per-thread contexts for decoding. Once
the decoder finishes, however, the per-thread contexts are not freed
normally, so these references leak.
The implicit checks via v_data_size and a_data_size don't work in the case
'(hdr_size > 7) && !ctx->alpha_info'.
This fixes segmentation faults due to invalid reads.
This problem was introduced in commit
547c2f002a.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The secondary compression in Hap is optional, this change exposes that option to
the user as some use-cases favour higher bitrate files to reduce workload
decoding.
Adds "none" or "snappy" as options for "compressor". Selecting "none" disregards
"chunks" option: chunking is only of benefit decompressing Snappy.
Reviewed-by: Martin Vignali <martin.vignali@gmail.com>
Signed-off-by: Tom Butterworth <bangnoise@gmail.com>
This fixes crashes since 557c1675cf in linux PIC builds.
Previously, movrelx silently used r12 as helper register, which
doesn't work when r12 is the destination register.
Signed-off-by: Martin Storsjö <martin@martin.st>
We reset .Lpic_gp to zero at the start of each function, which means
that the logic within movrelx for clearing gp when necessary will
be missed.
This fixes using movrelx in different functions with a different
helper register.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
The speedup for the large horizontal filters is surprisingly
big on A7 and A53, while there's a minor slowdown (almost within
measurement noise) on A8 and A9.
Cortex A7 A8 A9 A53
orig:
vp9_put_8tap_smooth_64h_neon: 20270.0 14447.3 19723.9 10910.9
new:
vp9_put_8tap_smooth_64h_neon: 20165.8 14466.5 19730.2 10668.8
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; it is essentially a 1:1
port with no extra added features, but with some hand tuning
(especially for the plain copy/avg functions). The ARM version
isn't very register starved to begin with, so there's not much
to be gained from having more spare registers here - we only
avoid having to clobber callee-saved registers.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_avg4_neon: 27.2 23.7
vp9_avg8_neon: 56.5 54.7
vp9_avg16_neon: 169.9 167.4
vp9_avg32_neon: 585.8 585.2
vp9_avg64_neon: 2460.3 2294.7
vp9_avg_8tap_smooth_4h_neon: 132.7 125.2
vp9_avg_8tap_smooth_4hv_neon: 478.8 442.0
vp9_avg_8tap_smooth_4v_neon: 126.0 93.7
vp9_avg_8tap_smooth_8h_neon: 241.7 234.2
vp9_avg_8tap_smooth_8hv_neon: 690.9 646.5
vp9_avg_8tap_smooth_8v_neon: 245.0 205.5
vp9_avg_8tap_smooth_64h_neon: 11273.2 11280.1
vp9_avg_8tap_smooth_64hv_neon: 22980.6 22184.1
vp9_avg_8tap_smooth_64v_neon: 11549.7 10781.1
vp9_put4_neon: 18.0 17.2
vp9_put8_neon: 40.2 37.7
vp9_put16_neon: 97.4 99.5
vp9_put32_neon/armv8: 346.0 307.4
vp9_put64_neon/armv8: 1319.0 1107.5
vp9_put_8tap_smooth_4h_neon: 126.7 118.2
vp9_put_8tap_smooth_4hv_neon: 465.7 434.0
vp9_put_8tap_smooth_4v_neon: 113.0 86.5
vp9_put_8tap_smooth_8h_neon: 229.7 221.6
vp9_put_8tap_smooth_8hv_neon: 658.9 621.3
vp9_put_8tap_smooth_8v_neon: 215.0 187.5
vp9_put_8tap_smooth_64h_neon: 10636.7 10627.8
vp9_put_8tap_smooth_64hv_neon: 21076.8 21026.9
vp9_put_8tap_smooth_64v_neon: 9635.0 9632.4
These are generally about as fast as the corresponding ARM
routines on the same CPU (at least on the A53), in most cases
marginally faster.
The speedup vs C code is pretty much the same as for the 32 bit
case; on the A53 it's around 6-13x for ther larger 8tap filters.
The exact speedup varies a little, since the C versions generally
don't end up exactly as slow/fast as on 32 bit.
Signed-off-by: Martin Storsjö <martin@martin.st>
With apple tools, the linker fails with errors like these, if the
offset is negative:
ld: in section __TEXT,__text reloc 8: symbol index out of range for architecture arm64
Signed-off-by: Martin Storsjö <martin@martin.st>
FLAC streams originating from the FLAC encoder send updated and more
complete STREAMINFO metadata as part of the last packet, so write that
to CodecPrivate instead of the incomplete one available in extradata
during init.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
aac_adtstoasc makes the aac extradata available only after the first packet
is filtered, and as packet side data.
Assume extradata will be available as part of the first packet if
avpriv_mpeg4audio_get_config() fails the first time due to missing extradata
and reserve space for the OutputSampleRate element in the Tracks master.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Add keyframe index metadata
Used to facilitate seeking; particularly for HTTP pseudo streaming.
1. read live streaming or file by sequence
2. if use add_keyframe_index option, add a mark flag at the position,
use to insert new context at the last step.
3. add the keyframes *offset* and *timestamp* into a list
4. if use add_keyframe_index option, shift the metadata data from
mark flag offset
5. insert the keyframes *offset* and *timestamp* from the list by
sequence
6. free the list
7. end.
Add FATE test case;
Reviewed-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Steven Liu <liuqi@gosun.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This allows a subsequent change to compress directly into the output packet when possible.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Tom Butterworth <bangnoise@gmail.com>
If the value is negative then it means padding at the start of the packet
instead of at the end.
Based on a patch by Hendrik Leppkes.
Reviewed-by: James Zern <jzern-at-google.com@ffmpeg.org>
Signed-off-by: James Almer <jamrial@gmail.com>
Compare using AVCodecParameters instead of the deprecated
AVStream.codec field
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The libopus encoder does the same thing and its better than
keeping track of when the empty flush frames appear.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The API does not allow returning AVERROR codes.
It triggers an assert in av_parser_parse2.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Commit 04964ac311 ("avformat/hls: Fix missing streams in some
cases with MPEG TS") caused a regression where subdemuxer streams that
use probing (e.g. dts/eac3/mp2 in mpegts) no longer get probed properly.
This is because the codec parameters from the subdemuxer stream, once
probed, are not passed on to the main stream.
Fix that by updating the codec parameters if the codec id changes.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
This will allow implementing the allocator more fully, which is needed
by the HEVC encoder plugin with video memory input.
Signed-off-by: Maxym Dmytrychenko <maxym.dmytrychenko@intel.com>
For encoding, this avoids modifying the input surface, which we are not
allowed to do.
This will also be useful in the following commits.
Signed-off-by: Maxym Dmytrychenko <maxym.dmytrychenko@intel.com>
Uploading/downloading data through VPP may not work for some formats, in
that case we can still try to call av_hwframe_transfer_data() on the
child context.
Signed-off-by: Maxym Dmytrychenko <maxym.dmytrychenko@intel.com>
Certain pixel formats (e.g. P8) might not be supported for
download/upload through VPP operations, but can still be used otherwise.
Signed-off-by: Maxym Dmytrychenko <maxym.dmytrychenko@intel.com>
When using GPU surfaces with QSV, one needs to supply a frame allocator,
which will be invoked to pass surface pools to libmfx.
For encoding, this allocator gets invoked not only for the pool of input
frames, but also for a separate pool of (apparently) reconstructed frames
and another pool of MFX_FOURCC_P8, which on Windows needs to return
D3DFMT_P8 D3D surfaces. Those are probably used to store the encoded
bitstream on the GPU.
Signed-off-by: Maxym Dmytrychenko <maxym.dmytrychenko@intel.com>
AVCodecParameters.sample_rate is a signed integer, so
XMVAudioPacket.sample_rate should be, too.
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Also check for errors from avpriv_mpeg4audio_get_config in
ff_mp4_read_dec_config_descr.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
fate-aac-al07_96 fails if sample_rate == 0 is rejected in
ff_mov_read_stsd_entries.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This is required since some programs are not able to correctly recognize
the metadata. See H.222, 2.6.58 Metadata pointer descriptor.
putstr8() is modified in order to allow to skip writing the string
length.
This should be more useful for users since numerical values for channel
layout can be confusing and unintuitive.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
When ffplay is used to play from the RTSP URL that serves 24 bit audio
content, ffplay fails to recognize the audio codec format. The attached
patch adds support for playing 24 bit audio content over RTSP by
defining a dynamic payload handler for "L24".
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
libavcodec/x86/rv40dsp_init.c:97:2: warning: ISO C does not allow extra ‘;’ outside of a function [-Wpedantic]
libavcodec/x86/vp9dsp_init.c:94:40: warning: ISO C does not allow extra ‘;’ outside of a function [-Wpedantic]
Fixes valgrind warnings about usage of uninitialized values.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
The bitstream filters do not work with merged in side data
This leaves the input packet split if it is being split.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This reverts commit fba2a8a254.
The changes were right for av_write_frame() but not for av_interleaved_write_frame().
The following commit will fix this in a simpler way.
Signed-off-by: James Almer <jamrial@gmail.com>
In recent lld-link versions, this command prints the version to
stdout, but also prints an error to stderr:
$ lld-link -flavor gnu --version
LLD 4.0.0 (trunk 285641)
lld-link: error: no input files
lld-link: error: target emulation unknown: -m or at least one .o file required
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes errors like this when building non-pic binaries with armv6
as baseline:
Error: invalid literal constant: pool needs to be closer
Signed-off-by: Martin Storsjö <martin@martin.st>
Otherwise it can be non-zero next time decode_lowdelay is called, causing
slice_params_buf not to be allocated, leading to a NULL pointer dereference.
The problem was introduced in commit
dcad4677d6.
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
"Vidvox Hap", not "Vidvox Hap encoder" or "Vidvox Hap decoder". Fixes
bad name in "ffmpeg -codecs", matches other codec naming.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
2-channels convolution using complex fft
improves speed significantly
not sure if it should be enabled by default
so disable it by default
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
Takes a frame associated with a hardware context as input and maps it
to something else (another hardware frame or normal memory) for other
processing. If the frame to map was originally in the target format
(but mapped to something else), the original frame is output.
Also supports mapping backwards, where only the output has a hardware
context. The link immediately before will be supplied with mapped
hardware frames which it can write directly into, and this filter
then unmaps them back to the actual hardware frames.
Adds the new av_hwframe_map() function, which allows mapping between
hardware frames and normal memory, along with internal support for
implementing it.
Also adds av_hwframe_ctx_create_derived(), for creating a hardware
frames context associated with one device using frames mapped from
another by some hardware-specific means.
this is somewhat a magic number, which can be understood from reading section
"7.1.2 Exponent Strategy" of the ac3 specification, in short:
Three exponents each represented as number 0-4 are grouped together and
base-5 encoded, so the maximal correct value is 25*4 + 5*4 + 4 = 124.
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The framework will allocate a buffer and copy the data to it,
that takes time. But it avoids constently creating and
destroyng the shared memory segment, and that saves more time.
On my setup,
from ~200 to ~300 FPS at full screen (1920×1200),
from ~1400 to ~3300 at smaller size (640×480),
similar to legacy x11grab and confirmed by others.
Plus, shared memory segments are a scarce resource,
allocating potentially many is a bad idea.
Note: if the application were to drop all references to the
buffer before the next call to av_read_frame(), then passing
the shared memory segment as a refcounted buffer would be
even more efficient, but it is hard to guarantee, and it does
not happen with the ffmpeg command-line tool. Using a small
number of preallocated buffers and resorting to a copy when
the pool is exhausted would be a solution to get the better
of both worlds.
According to spec ISO_IEC_15444_12 "For any media stream for which no segment index is present, referred to as non‐indexed stream, the media stream associated with the first Segment Index box in the segment serves as a reference stream in a sense that it also describes the subsegments for any non‐indexed media stream."
Signed-off-by: Sasi Inguva <isasi@google.com>
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
libavutil/x86/float_dsp_init.c(144) : warning C4028: formal parameter 1 different from declaration
libavutil/x86/float_dsp_init.c(144) : warning C4028: formal parameter 2 different from declaration
libavcodec/dnxhdenc.c(326) : warning C4028: formal parameter 1 different from declaration
libavcodec/dnxhdenc.c(329) : warning C4028: formal parameter 1 different from declaration
libavcodec/pixblockdsp.c(58) : warning C4028: formal parameter 1 different from declaration
libavcodec/pixblockdsp.c(63) : warning C4028: formal parameter 1 different from declaration
libavcodec/pixblockdsp.c(66) : warning C4028: formal parameter 1 different from declaration
libavcodec/ituh263dec.c(215) : warning C4028: formal parameter 1 different from declaration
libavcodec/ituh263dec.c(215) : warning C4028: formal parameter 2 different from declaration
The include of config.h was added in 2012 in 1d9c2dc8, due to
the use of CONFIG_SNOW_ENCODER ifdefs within options_table.h.
When the snow codec was dropped later (in a0c5917f8 in 2013),
this include no longer served any purpose.
options_table.h is included in builds for the host as well, when
building documentation. config.h should not be included in code
that is built for the host, since it can contain workarounds
for the target compiler/environment, like adding a missing define
of restrict, defining getenv(x) to NULL for environments that lack
getenv.
The seemingly innocent include reordering in 2025d37871 broke
builds that have getenv(x) defined to NULL in config.h (Windows CE
and Windows Phone/RT), since libavcodec/options_table.h include
config.h, while libavformat/options_table.h end up bringing in
more system headers, and those system headers can contain a proper
definition of getenv, which clash with the getenv define in config.h.
This was avoided earlier as long as libavformat/options_table.h (or
avformat.h) was included before libavcodec/options_table.h.
This fixes builds for Windows Phone/RT and CE.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
The filter coefficients are signed values, where the product of the
multiplication with one individual filter coefficient doesn't
overflow a 16 bit signed value (the largest filter coefficient is
127). But when the products are accumulated, the resulting sum can
overflow the 16 bit signed range. Instead of accumulating in 32 bit,
we accumulate the largest product (either index 3 or 4) last with a
saturated addition.
(The VP8 MC asm does something similar, but slightly simpler, by
accumulating each half of the filter separately. In the VP9 MC
filters, each half of the filter can also overflow though, so the
largest component has to be handled individually.)
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_avg4_neon: 1.71 1.15 1.42 1.49
vp9_avg8_neon: 2.51 3.63 3.14 2.58
vp9_avg16_neon: 2.95 6.76 3.01 2.84
vp9_avg32_neon: 3.29 6.64 2.85 3.00
vp9_avg64_neon: 3.47 6.67 3.14 2.80
vp9_avg_8tap_smooth_4h_neon: 3.22 4.73 2.76 4.67
vp9_avg_8tap_smooth_4hv_neon: 3.67 4.76 3.28 4.71
vp9_avg_8tap_smooth_4v_neon: 5.52 7.60 4.60 6.31
vp9_avg_8tap_smooth_8h_neon: 6.22 9.04 5.12 9.32
vp9_avg_8tap_smooth_8hv_neon: 6.38 8.21 5.72 8.17
vp9_avg_8tap_smooth_8v_neon: 9.22 12.66 8.15 11.10
vp9_avg_8tap_smooth_64h_neon: 7.02 10.23 5.54 11.58
vp9_avg_8tap_smooth_64hv_neon: 6.76 9.46 5.93 9.40
vp9_avg_8tap_smooth_64v_neon: 10.76 14.13 9.46 13.37
vp9_put4_neon: 1.11 1.47 1.00 1.21
vp9_put8_neon: 1.23 2.17 1.94 1.48
vp9_put16_neon: 1.63 4.02 1.73 1.97
vp9_put32_neon: 1.56 4.92 2.00 1.96
vp9_put64_neon: 2.10 5.28 2.03 2.35
vp9_put_8tap_smooth_4h_neon: 3.11 4.35 2.63 4.35
vp9_put_8tap_smooth_4hv_neon: 3.67 4.69 3.25 4.71
vp9_put_8tap_smooth_4v_neon: 5.45 7.27 4.49 6.52
vp9_put_8tap_smooth_8h_neon: 5.97 8.18 4.81 8.56
vp9_put_8tap_smooth_8hv_neon: 6.39 7.90 5.64 8.15
vp9_put_8tap_smooth_8v_neon: 9.03 11.84 8.07 11.51
vp9_put_8tap_smooth_64h_neon: 6.78 9.48 4.88 10.89
vp9_put_8tap_smooth_64hv_neon: 6.99 8.87 5.94 9.56
vp9_put_8tap_smooth_64v_neon: 10.69 13.30 9.43 14.34
For the larger 8tap filters, the speedup vs C code is around 5-14x.
This is significantly faster than libvpx's implementation of the same
functions, at least when comparing the put_8tap_smooth_64 functions
(compared to vpx_convolve8_horiz_neon and vpx_convolve8_vert_neon from
libvpx).
Absolute runtimes from checkasm:
Cortex A7 A8 A9 A53
vp9_put_8tap_smooth_64h_neon: 20150.3 14489.4 19733.6 10863.7
libvpx vpx_convolve8_horiz_neon: 52623.3 19736.4 21907.7 25027.7
vp9_put_8tap_smooth_64v_neon: 14455.0 12303.9 13746.4 9628.9
libvpx vpx_convolve8_vert_neon: 42090.0 17706.2 17659.9 16941.2
Thus, on the A9, the horizontal filter is only marginally faster than
libvpx, while our version is significantly faster on the other cores,
and the vertical filter is significantly faster on all cores. The
difference is especially large on the A7.
The libvpx implementation does the accumulation in 32 bit, which
probably explains most of the differences.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes it match the pattern already used for VP8 MC functions.
This also makes the signature match ffmpeg's version of these
functions, easing porting of code in both directions.
Signed-off-by: Martin Storsjö <martin@martin.st>
This was broken by the following Libav commit:
4c387c7 ppc: dsputil: do unaligned block accesses correctly
The following tests fail due to this:
fate-checkasm
fate-vsynth1-dnxhd-2k-hr-hq fate-vsynth1-dnxhd-edge1-hr
fate-vsynth1-dnxhd-edge2-hr fate-vsynth1-dnxhd-edge3-hr
fate-vsynth1-dnxhd-hr-sq-mov fate-vsynth1-dnxhd-hr-hq-mov
fate-vsynth2-dnxhd-2k-hr-hq fate-vsynth2-dnxhd-edge1-hr
fate-vsynth2-dnxhd-edge2-hr fate-vsynth2-dnxhd-edge3-hr
fate-vsynth2-dnxhd-hr-sq-mov fate-vsynth2-dnxhd-hr-hq-mov
fate-vsynth3-dnxhd-2k-hr-hq fate-vsynth3-dnxhd-edge1-hr
fate-vsynth3-dnxhd-edge2-hr fate-vsynth3-dnxhd-edge3-hr
fate-vsynth3-dnxhd-hr-sq-mov fate-vsynth3-dnxhd-hr-hq-mov
Fixes trac ticket #5508.
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The parser depends on the codec and thus must not be used with a different one.
If it is, the 'avctx->codec_id == s->parser->codec_ids[0] ...' assert in
av_parser_parse2 gets triggered.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The old code had to retain a partial frame across two calls in
the case of separate interlaced fields. Now, we know that we'll
get both fields within the same receive_frame call, and so we
don't need to manage the frame as private state any more.
It's not possible to return EAGAIN when we've passed input EOF and are
in draining mode. If do return EAGAIN, we're saying there's no way to
get any more output - which isn't true in many cases.
So let's handled these cases in an internal loop as best we can.
It seems that without all the other 1:1 heuristics, we don't have
a fundamental problem trusting the interlaced flag on output
pictures. That's a relief.
I'm not sure why, but the mpeg4_unpack_bframes bsf is not
interacting well with seeking. Looking at the code, it should be
ok, with possibly one warning shown, but I see it getting stuck
for an extended period of time after a seek where a packed frame
is cached to be shown later.
So, I gave up on that and went back to making the old hardware
based path work. Turns out that it wasn't broken except that some
samples have a 6 byte drop packet which I wasn't accounting for.
Now it works again and seeks are good.
The new decode API allows for m:n decode patterns, which is what
you need to use this hardware in a sane way. There are so many
situations where 1:1 doesn't happen naturally that it's a miracle
I got it working as well as I did.
With this change, we can throw all of the crazy heuristics and
sleeps(!) out, and things work correctly.
Why on earth the hardware returns garbage for the first sample of
a decoded picture is anyone's guess. The simplest reasonable way
to patch it up is to copy the first sample of the second line. This
should result in the correct chroma values (because the data was
original 4:2:0 upsampled to 4:2:2) even if the luma is isn't.
Also adds a new flag to mark filters which are aware of hwframes and
will perform this task themselves, and marks all appropriate filters
with this flag.
This is required to allow software-mapped hardware frames to work,
because we need to have the frames context available for any later
mapping operation in the filter graph.
The output from the filter graph should only propagate further to an
encoder if the hardware format actually matches the visible format
(mapped frames are valid here and have an hw_frames_ctx, but this
should not be given to the encoder as its hardware context).
This avoids potential rounding errors and guarantees the source aspect
ratio is preserved.
Keep writing pixel values when Stereo 3D Mode is enabled and for WebM,
as the format doesn't support anything else.
This fixes ticket #5743, implementing the suggestion from ticket #5903.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes the following warning:
libavcodec/hapenc.c:122:20: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘size_t’ [-Wformat]
Based on a patch by Diego Biurrun.
If there are no index entries, e_old = st->index_entries is only one
byte large, since it was created by av_realloc called with size 0.
Thus accessing e_old[0].timestamp causes a heap buffer overflow.
Reviewed-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This matrix needs to be applied after all others have (currently only
display matrix from trak), but cannot be handled in movie box, since
streams are not allocated yet. So store it in main context, and apply
it when appropriate, that is after parsing the tkhd one.
Fate tests are updated accordingly.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This is needed for improved fate testing and it is modeled after
-show_format_entry. The main behavioral difference is that when a print
function is called with an empty key, rather than discarding it, the
closes key in the hierarchy is used instead.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The use of TLSv1_*_method() disallows newer protocol versions; instead
use SSLv23_*_method() and then explicitly disable the deprecated
protocol versions which should not be supported.
Merged as-at libav 398f015, and therefore includes outstanding
skipped merges 04b17ff and 130e1f1.
All features not in libav are preserved, and no options change.
pkg-config(1) expects uninstalled pc files to follow the
blah-uninstalled.pc naming convention and the behavior
of the program is impacted by it. Without this fix
overriding PKGP_CONFIG_LIBDIR is required to ensure
uninstalled files are preferred (overkill), instead of
just adding pc-uninstalled/ to the utility's search path
by setting PKG_CONFIG_PATH accordingly.
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
The number of channels is used as divisor in decode_frame, so it must
not be zero to avoid SIGFPE crashes.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The use of TLSv1_*_method() disallows newer protocol versions; instead
use SSLv23_*_method() and then explicitly disable the deprecated
protocol versions which should not be supported.
Fixes ticket #5915.
libavcodec/hapenc.c:121:20: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘size_t {aka unsigned int}’ [-Wformat=]
libavcodec/hapenc.c:121:20: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘size_t {aka unsigned int}’ [-Wformat=]
Since avversion.h is a generated header it must be created before
dependencies can be determined as a side effect of compilation.
Otherwise Make stops and restarts the build process to generate
avversion.h and produces related error messages.
The dynamic buffer does not contain the CRC32 element so calls to avio_tell()
don't take it into account. This resulted in CueRelativePosition values being
six bytes short.
This is a regression since 6724525a15
Instead of adding yet another custom check for CRC32 to fix a size or an offset,
remove the existing ones and reserve the six bytes in the dynamic buffer.
Signed-off-by: James Almer <jamrial@gmail.com>
When the macro is expanded with a semicolon following it and the
macro itself contains a semicolon, we ended up in double semicolons,
which is treated as a statement that disallows further declarations.
This avoids errors about mixed declarations and statements on gcc,
after ee05079766.
Signed-off-by: Martin Storsjö <martin@martin.st>
The buffer map/unmap code was in an early version of this before it
was committed, but the unmap was never removed. While wrong, this
was harmless (and therefore unnoticed) because the buffers can't be
mapped at this point - all drivers just did nothing with the call.
Use new H264Ref.reference field to track field picture flags. The
H264Picture.reference flag in DPB is now irrelevant here.
This is a regression from git commit a12d3188, and that affected
multiple interlaced video streams.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
When decoding interlaced pictures, the structure is reused to render
to the same surface twice. The parameter buffers were not being
cleared, which caused the i965 driver to error out.
Instead use our own struct, which we already use when using
gcrypt and gnutls.
In OpenSSL 1.1, the DH struct has been made opaque.
Signed-off-by: Martin Storsjö <martin@martin.st>
sigaction is not defined in standards as a struct starting with another
struct. Some *BSD variants do however, resulting in a warning from the
zero initialization, which this change eliminates.
This partially reverts a92be9b856.
For 'nclx', the latest edition of the standard switched from JPEG XR
to 23001-8, which matches the current order of our entries. Bounds
are preserved as a sanity check.
For 'nclc', qtff edition 2016-09-13 introduced a few new entries.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
x29 (FP) is a callee saved register and should be restored on
return. Instead of backing up x29 and restoring it here, back up
sp in a register that we are allowed to overwrite.
This fixes crashes in checkasm on aarch64 since f1b3e13138.
For some reason, gcc builds didn't crash, but clang builds do.
Signed-off-by: Martin Storsjö <martin@martin.st>
This, combined with clobbering the stack space prior to the call,
increases the chances of finding cases where 32 bit parameters
are erroneously treated as 64 bit.
Signed-off-by: Martin Storsjö <martin@martin.st>
Even if MAX_ARGS - 2 (for arm) or MAX_ARGS - 7 (for aarch64) parameters
are passed on the stack to checkasm_checked_call, we actually only
need to store MAX_ARGS - 4 (for arm) or MAX_ARGS - 8 (for aarch64)
parameters on the stack when calling the tested function.
Signed-off-by: Martin Storsjö <martin@martin.st>
This also fixes a minor bug introduced in the codecpar conversion, where
the termination condition for extracting the extradata does not match
the actual extradata setting code. As a result, the packet durations
made up by lavf go back to their values before the codecpar conversion.
That is of little consequence since that code should eventually be
dropped completely.
This way they can be reused by other code without including the whole
decoder-specific hevcdec.h
Also, add the HEVC_ prefix to them, since similarly named values exist
for H.264 as well and are sometimes used in the same code.
The spec says
9: Interlaced with bottom field displayed first and top field stored first
14: Interlaced with top field displayed first and bottom field stored first
And avcodec.h states
AV_FIELD_TB, //< Top coded first, bottom displayed first
AV_FIELD_BT, //< Bottom coded first, top displayed first
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
According to the public RTMP specification, these 4 bytes should
be zero.
librtmp in server mode assumes that the RTMPE (FP9) handshake is
used if these bytes are nonzero.
Signed-off-by: Martin Storsjö <martin@martin.st>
When acting as server, the server can include a "clientid" property
in some status messages. But this should be a unique number
identifying the client session, not identifying the server itself.
In practice, omitting it works just as well as including this
incorrect field.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure that e.g. Adobe FME actually reacts to it. As long
as the value we've been sending is the default one (128), the bug
hasn't been noticed.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some applications such as Adobe FME append lots of parameters
here, making it easily overflow the current limit.
Signed-off-by: Martin Storsjö <martin@martin.st>
The decoding buffer index expected by D3D11VA is the one from the
ID3D11Texture2D not the one from the ID3D11VideoDecoderOutputView array
in AVD3D11VAContext.
Otherwise, when providing decoder slices that do not start from 0,
pictures appear in bogus order. For an invalid index crashes and
image corruption can occur.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
filter16 goes from 508 to 482 (h) or 346 to 314 (v) cycles; filter88
goes from 240 to 238 (h) or 174 to 165 (v) cycles, measured on TOS.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Similar gains as the ssse3 version once again
Additional improvements by Clément Bœsch <u@pkh.me>.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The randomize_buffer() implementation assures that "most of the time",
we'll do a good mix of wide16/wide8/hev/regular/no filters for complete
code coverage. However, this is not mathematically assured because that
would make the code either much more complex, or much less random.
Some fixes and improvements by Rodger Combs <rodger.combs@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This was not observed earlier because the only syntax element which
it normally misses with the current setup is slice_qp_delta, but that
is always going to be zero (in IDR frames QP isn't varied on the
slice) which will always exp-golomb code as a single 1 bit. The
immediately following part is the byte alignment, which is always a 1
bit followed by 0s which are ignored, so as long as the bitstream is
never aligned at that point we will never notice because the only
difference is that an ignored bit is a 1 instead of a 0.
Errors during decoding are currently considered non-fatal and do not
terminate transcoding, so even if parts of the data are corrupted, the
rest may be decodable.
However, that should apply only to the actual decoding calls, not to the
failures elsewhere (e.g. configuring filters).
The filtergraph's existence is used in several places to mean that the
filtergraph is fully configured. This causes problems if it's allocated,
but the initialization fails (e.g. if a non-existent filter is
specified).
Adds a wrapper function for downmixing which detects channel count changes
and updates the selected downmix function accordingly.
Simplification and porting to current x86inc infrastructure by Diego Biurrun.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Also use (float **) instead of (float (*)[2]). This matches the matrix
layout in libavresample so we can reuse assembly code between the two.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
It is supposed to be a flag. The only currently defined value is
AVIO_SEEKABLE_NORMAL, but other ones may be added in the future.
However all the current lavf code treats this field as a bool (mainly
for historical reasons).
Change all those cases to properly check for AVIO_SEEKABLE_NORMAL.
While outwardly bizarre, this change makes the behaviour consistent
with other VAAPI encoders which sync to the encode /input/ picture in
order to wait for /output/ from the encoder. It is not harmful on
i965 (because synchronisation already happens in vaRenderPicture(),
so it has no effect there), and it allows the encoder to work on
mesa/gallium which assumes this behaviour.
This allows better checking of capabilities and will make it easier
to add more functionality later.
It also commonises some duplicated code around rate control setup
and adds more comments explaining the internals.
Follow a 420, 422, 444 order instead of a random one.
This simplifies double-checking additions of new formats.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This version, which is the only one doing two processing cycles per loop
iteration, computes the load/store indices incorrectly for the second
cycle.
CC: libav-stable@libav.org
This was introduced in bc2a32969e.
The whole block that the statement was added to is only
relevant when used as a demuxer, but the other statements
there have had other if statements guarding them. Make
sure to only run this whole block if being used as a
demuxer.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
If the input has been decoded from a stream which uses edge cropping
then the whole surface need not be valid. This defines an input
region for the scaler so we only use the active area of the frame.
This avoids SIMD-optimized functions having to sign-extend their
line size argument manually to be able to do pointer arithmetic.
Also adjust parameter names to be "stride" everywhere.
The latter can do everything the former can do, but also handle conditions
the former cannot like multiple header #includes and checking for headers
and functions in a single test program, which is necessary for certain
library tests.
With some old libva versions <va/va.h> does not automatically include
the per-codec subsidiary headers, so we need to include the right one
explicitly ourselves.
After init_opts() there needs to be an uninit_opts() call
to free the swscale context and other buffers.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This was added before edts support existed, and is no longer
valid.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This breaks files with legitimate single-entry edit lists,
and the hack, introduced in f03a081df0,
has no link to any known sample in its commit message.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
libavcodec/libvpxdec.c:100:57: warning: passing argument 3 of 'av_image_copy' from incompatible pointer type
av_image_copy(picture->data, picture->linesize, img->planes,
libavutil/imgutils.h:116:6: note: expected 'const uint8_t **' but argument is of type 'unsigned char **'
void av_image_copy(uint8_t *dst_data[4], int dst_linesizes[4],
This avoids SIMD-optimized functions having to sign-extend their
line size argument manually to be able to do pointer arithmetic.
Also adjust parameter names to be "linesize" everywhere.
This avoids SIMD-optimized functions having to sign-extend their
stride argument manually to be able to do pointer arithmetic.
Also adjust parameter names to be "stride" everywhere.
The code currently reads the coded dimensions from the extradata, but
expects the display dimensions to be set by the caller, and does not
check that they are compatible (i.e. that the displayed size is smaller
than the coded size).
Make sure that when the display dimensions are set, they are also valid.
Fixes possible invalid memory access.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
It is passed to the get_bits API, which requires buffers to be padded.
Fixes possible invalid reads.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
height - me_y is the line from which we read, so it must be strictly
smaller than the frame height. Fixes possible invalid reads in corrupted
files.
Also, use a proper context for logging the error.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
If we encounter an END element before anything is decoded, we would
return success even though the output frame has not been allocated,
which is invalid.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
If no string argument is supplied when av_hwdevice_ctx_create() is
called to create a VAAPI device, we currently only try the default
X11 display (that is, $DISPLAY) to find a device, and will therefore
fail in the absence of an X server to connect to. Change the logic
to also look for a device via the first DRM render node (that is,
"/dev/dri/renderD128"), which is probably the right thing to use in
most simple configurations which only have one DRM device.
We need more information from last/cur_frame than from reference
buffers, so we can use a simplified structure for reference buffers,
and then store mvs and segmentation map information in last/cur.
This prepares the decoder for frame threading support.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Not from the underlying frame. Fixes races with frame threading in
field-coded files, where decoding would wait for the wrong field (e.g.
random failures in mixed-nal-coding).
Bug-Id: 954
A non-existent av_buffer_pool_can_uninit() function is mentioned instead
of av_buffer_pool_uninit(). Also, this function is to be called by the
caller, not the pool itself.
The frame dimensions are 16bit, so the mv bounds can easily overflow
int16 for large videos.
Bug-Id: Handbrake/46
CC: libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>
In such a case behave as if the buffer was not reallocatable -- allocate a
new one and copy the data (preserving just the part described by the
reference passed to av_buffer_realloc).
CC: libav-stable@libav.org
Reported-By: wm4 <nfxjfg@googlemail.com>
pavgb is an sse integer instruction, so the mmxext flag is enough
Signed-off-by: James Almer <jamrial@gmail.com>
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This reverts commit 014773b66b.
Since 230b1c070, the bytewise AV_W*() macros only expand their
argument once, i.e. doing exactly the same change as was done
in the AV_COPY*U macros, so this change is no longer necessary.
Signed-off-by: Martin Storsjö <martin@martin.st>
This reverts commit 25bacd0a0c.
Since 230b1c070, the bytewise AV_W*() macros only expand their
argument once, so revert to the more readable version of these.
Signed-off-by: Martin Storsjö <martin@martin.st>
AV_WN64 is meant for unaligned data, but the existing av_alias* unions
(without a definition for the av_alias attribute - we don't have one
for MSVC) indicate to the compiler that they would have sufficient
alignment for normal access, i.e. the compiler is free to assume
8 byte alignment.
On ARM, this makes sure that AV_WN64 (or two consecutive AV_WN32) is
done with two str instructions instead of one strd.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids issues with expanding the argument multiple times,
and makes sure that it is of the right type for the following shifts.
Even if the caller of a macro could be expected not to pass parameters
that have side effects if expanded multiple times, these fallback
codepaths are rarely, if ever, tested, so it is expected that such
issues can arise.
Thefore, for safety, make sure the fallback codepaths only expand
the arguments once.
Signed-off-by: Martin Storsjö <martin@martin.st>
If AV_RN and AV_WN are macros with multiple individual reads and
writes, the previous version of the AV_COPYU macro would fail if
the reads and writes overlap.
This should not be any less efficient in any case, given a
sensibly optimizing compiler.
Signed-off-by: Martin Storsjö <martin@martin.st>
AV_WB32 can be implemented as a macro that expands its parameters
multiple times (in case AV_HAVE_FAST_UNALIGNED isn't set and the
compiler doesn't support GCC attributes); make sure not to read
multiple times from the source in this case.
Signed-off-by: Martin Storsjö <martin@martin.st>
The reference frames are used in update_thread_context(), so modifying
them after finish_setup() is a race. The frame in question will be
released during the next decode call.
CC: libav-stable@libav.org
This allows doing this redirection, if building with clang against
old enough MSVC headers that lack strtoll (2012 and older).
Signed-off-by: Martin Storsjö <martin@martin.st>
This reverts commit 0e0538aefc.
The valgrind warning was a false positive due to OSX implementation of
printf (invoking a strnlen), while this code is actually fine, since the
format specifier %.*s guarantes that no more than buf_size bytes from
buf will be read.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Clang normally disguises as GCC (defining __GNUC__), and thus get
all the normal GCC specific attributes.
Clang can also work as a drop-in replacement for MSVC, and in these
cases, it doesn't define __GNUC__, but defines _MSC_VER instead.
Even in these setups, it still supports the GCC style attributes,
thus use them, especially where there isn't any MSVC specific
version, or where the MSVC specific version doesn't work on clang
(for DECLARE_ASM_CONST).
Signed-off-by: Martin Storsjö <martin@martin.st>
When targeting COFF (windows), clang doesn't support this
directive (while binutils supports it for all targets).
Signed-off-by: Martin Storsjö <martin@martin.st>
There are samples with invalid stsc that may work fine as is and
do not need extradata change. So ignore any out of range index, and
error out only when explode is set.
Found-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The current code will ignore the init_get_bits() failure and do an
invalid read from the uninitialized GetBitContext.
Found-By: Jan Ruge <jan.s.ruge@gmail.com>
Bug-Id: 952
This fixes retrieving a valid profile for many of the FATE conformance samples,
allowing them to be properly decoded by the HWAccel after adding a profile check.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
These bits are set by exceptions in NEON instructions.
Also print the differing bits when FPSCR is clobbered,
and use bic instead of lsl, for clearing the topmost bits.
Signed-off-by: Martin Storsjö <martin@martin.st>
Each const block needs to be terminated by one endconst
invocation so either call endconst after each, or just
declare plain labels to the later strings.
This fixes errors such as this, on some binutils versions:
checkasm.S:38: Error: Macro `endconst' was already defined
Signed-off-by: Martin Storsjö <martin@martin.st>
Since we only know whether a NAL unit corresponds to a new field after
parsing the slice header, this requires reorganizing the calls to slice
parsing, per-slice/field/frame init and actual decoding.
In the previous code, the function for slice header decoding also
immediately started a new field/frame as necessary, so any slices
already queued for decoding would no longer be decodable.
After this patch, we first parse the slice header, and if we determine
that a new field needs to be started we decode all the queued slices.
This function's purpose is not very well defined. Currently it does two
(only marginally related) things: selecting the next output frame and
calling ff_thread_finish_setup() for frame threading. The first of those
more properly belongs under field_start(), while the second can be
called directly from decode_nal_units().
The stack used by checkasm_checked_call_vfp was a multiple of 4 when the
checked function is called. AAPCS requires a double word (8 byte)
aligned stack public interfaces. Since both calls are public interfaces
the stack is misaligned when the checked is called.
Might fix the SIGBUS error in the armv7-linux-clang-3.7 fate config.
Fixes a regression in ca2f19b9cc with some mov/mp4 files. The files have
several NAL units in the supposed single NAL unit after the size field.
Annex B start code prefixes are used to separate them. The first NAL unit
is correctly parsed but the buffer does not point to the next size field.
Instead semi random data (it seems to be the rbsp_stop_one_bit and the
start code prefix) is then parsed as length and will exceed the
remaining length of the buffer.
Patch based on the code in h264's decode_nal_units() and a similar
patch by Hendrik Leppkes in FFmpeg (a9bb4cf87d).
Bug-Id: ffmpeg/trac5529
Reported-By: Vittorio Giovara
Currently, SPS.mb_height is actually what the spec calls
PicHeightInMapUnits, which is half the frame height when interlacing is
allowed. Calling this 'mb_height' is quite confusing, and there are at
least two associated bugs where this field is treated as the actual
frame height - in the h264 parser and in the code computing maximum
reordering buffer size for a given level.
Fix those issues (and avoid possible future ones) by exporting the real
frame height in this field.
This comment isn't true, the height can be different from the width
for these functions (which is why the height is passed as a parameter
to them).
Signed-off-by: Martin Storsjö <martin@martin.st>
GNU as evaluates true as '-1' while Apple's variant and llvm's internal
assembler evaluate it as '1'. The best way to avoid this madness is to
eliminate boolean expressions instead of trying to fix it with
preprocessor directives. Use a direct formula to calculate the
required temporary space on the stack in
ff_put_vp8_{epel,bilin}{4,8,16}_h[246]v[246]_armv6().
Fixes a checkasm segfault in vp8dsp.mc when using llvm's internal
assembler for a non-Apple target.
When writing a fragmented file, we by default write an index pointing
to all the fragments at the end of the file. This causes constantly
increasing memory usage during the muxing. For live streams, the
index might not be useful at all.
A similar fragment index is written (but at the start of the file) if
the global_sidx flag is set. If ism_lookahead is set, we need to keep
data about the last ism_lookahead+1 fragments.
If no fragment index is to be written, we don't need to store information
about all fragments, avoiding increasing the memory consumption
linearly with the muxing runtime.
This fixes out of memory situations with long live mp4 streams.
Signed-off-by: Martin Storsjö <martin@martin.st>
The driver being used is detected inside av_hwdevice_ctx_init() and
the quirks field then set from a table of known device. If this
behaviour is unwanted, the user can also set the quirks field
manually.
Also adds the Intel i965 driver quirk (it does not destroy parameter
buffers used in a call to vaRenderPicture()) and detects that driver
to set it.
P010 is the 10-bit variant of NV12 (planar luma, packed chroma), using two
bytes per component to store 10-bit data plus 6-bit zeroes in the LSBs.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This preserves all the information in the codec parameters.
The wavpack ref changes are caused by the fact that now the sample
format is set, so matroskaenc can use it to set the bit depth.
Bug-Id: 945, along with the previous commit
This avoids listing the same feature multiple times in the
test output. Previously the output contained something like this:
SSE2:
- hevc_mc.qpel [OK]
- hevc_mc.epel [OK]
- hevc_mc.unweighted_pred [OK]
- hevc_mc.qpel [OK]
- hevc_mc.epel [OK]
- hevc_mc.unweighted_pred [OK]
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids the risk of accidentally clobbering such variables outside
of the macro if the same variables are used there.
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes valgrind warnings about conditional jumps based on
uninitialized data (even though the uninitialized data only ever
was compared with a direct copy of the same uninitialized data).
Signed-off-by: Martin Storsjö <martin@martin.st>
While it is less featureful (and slower) than the built-in H264
decoder, one could potentially want to use it to take advantage
of the cisco patent license offer.
Signed-off-by: Martin Storsjö <martin@martin.st>
The hw frame used as reference has an attached size but it need not
match the actual size of the surface, so enforcing that the sw frame
used in copying matches its size exactly is not useful.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The source frame may be cropped, so that its dimensions are smaller than
the pool dimensions. The transfer_data API requires the allocated size
of the destination frame to be the same as the pool size.
Be more careful when an input stream encounters EOF when its filtergraph
has not been configured yet. The current code would immediately mark the
corresponding output streams as finished, while there may still be
buffered frames waiting for frames to appear on other filtergraph
inputs.
This should fix the random FATE failures for complex filtergraph tests
after a3a0230a98
Previously we would allocate a new one for every frame. This instead
maintains an AVBufferPool of them to use as-needed.
Also makes the maximum size of an output buffer adapt to the frame
size - the fixed upper bound was a bit too easy to hit when encoding
large pictures at high quality.
This makes sure the actual stream parameters are used, which is
important mainly for hardware decoding+filtering cases, which would
previously require various weird workarounds to handle the fact that a
fake software graph has to be constructed, but never used.
This should also improve behaviour in rare cases where
avformat_find_stream_info() does not provide accurate information.
Currently, a filtergraph will pull in the output constraints from its
corresponding decoder context, which breaks proper layering. Instead,
explicitly send the constaints on the output parameters to the
filtergraph.
This is similar to what is done for filtergraph inputs in
30ab4c51a180610d9f1720c75518d763515c0d9f
Setting the filter input parameters is moved to init_input_stream(),
so that it is done before the decoder is opened, potentially overwriting
the information from avformat_find_stream_info() with less accurate
data.
This commit temporarily disables QSV transcoding with hw frames. The
functionality will be re-added in the following commits.
Currently, calling configure_filtergraph() will pull in the input
parameters from the corresponding decoder context. This has the
following disadvantages:
- the decoded frame is a more proper source for this information
- a filter accessing decoder data breaks proper layering
Add functions for explicitly sending the input stream parameters to a
filtergraph input - currently from a frame and a decoder. The decoder
one will be dropped in future commits after some more restructuring.
2016-06-25 11:20:50 +02:00
2447 changed files with 163990 additions and 57980 deletions
cudaVideoCreate_Default=0x00,/**< Default operation mode: use dedicated video engines */
cudaVideoCreate_PreferCUDA=0x01,/**< Use a CUDA-based decoder if faster than dedicated engines (requires a valid vidLock object for multi-threading) */
cudaVideoCreate_PreferDXVA=0x02,/**< Go through DXVA internally if possible (requires D3D9 interop) */
cudaVideoCreate_PreferCUVID=0x04/**< Use dedicated video engines directly */
* \fn CUresult CUDAAPI cuvidMapVideoFrame64(CUvideodecoder hDecoder, int nPicIdx, unsigned long long *pDevPtr, unsigned int *pPitch, CUVIDPROCPARAMS *pVPP);
unsignedintulMaxNumDecodeSurfaces;/**< Max # of decode surfaces (parser will cycle through these) */
unsignedintulClockRate;/**< Timestamp units in Hz (0=default=10000000Hz) */
unsignedintulErrorThreshold;/**< % Error threshold (0-100) for calling pfnDecodePicture (100=always call pfnDecodePicture even if picture bitstream is fully corrupted) */
unsignedintulMaxDisplayDelay;/**< Max display queue delay (improves pipelining of decode with display) - 0=no delay (recommended values: 2..4) */
unsignedintuReserved1[5];/**< Reserved for future use - set to 0 */
void*pUserData;/**< User data for callbacks */
PFNVIDSEQUENCECALLBACKpfnSequenceCallback;/**< Called before decoding frames and/or whenever there is a format change */
PFNVIDDECODECALLBACKpfnDecodePicture;/**< Called when a picture is ready to be decoded (decode order) */
PFNVIDDISPLAYCALLBACKpfnDisplayPicture;/**< Called whenever a picture is ready to be displayed (display order) */
void*pvReserved2[7];/**< Reserved for future use - set to NULL */
CUVIDEOFORMATEX*pExtVideoInfo;/**< [Optional] sequence header data from system layer */
NV_ENC_BUFFER_FORMAT_YUV444=0x00001000,/**< Planar YUV [Y plane followed by U and V planes] */
NV_ENC_BUFFER_FORMAT_YUV420_10BIT=0x00010000,/**< 10 bit Semi-Planar YUV [Y plane followed by interleaved UV plane]. Each pixel of size 2 bytes. Most Significant 10 bits contain pixel data. */
NV_ENC_BUFFER_FORMAT_YUV444_10BIT=0x00100000,/**< 10 bit Planar YUV444 [Y plane followed by U and V planes]. Each pixel of size 2 bytes. Most Significant 10 bits contain pixel data. */
NV_ENC_BUFFER_FORMAT_ARGB=0x01000000,/**< 8 bit Packed A8R8G8B8 */
NV_ENC_BUFFER_FORMAT_ARGB10=0x02000000,/**< 10 bit Packed A2R10G10B10. Each pixel of size 2 bytes. Most Significant 10 bits contain pixel data. */
NV_ENC_BUFFER_FORMAT_AYUV=0x04000000,/**< 8 bit Packed A8Y8U8V8 */
NV_ENC_BUFFER_FORMAT_ABGR=0x10000000,/**< 8 bit Packed A8B8G8R8 */
NV_ENC_BUFFER_FORMAT_ABGR10=0x20000000,/**< 10 bit Packed A2B10G10R10. Each pixel of size 2 bytes. Most Significant 10 bits contain pixel data. */
NV_ENC_BUFFER_FORMAT_ARGB=0x01000000,/**< 8 bit Packed A8R8G8B8. This is a word-ordered format
where a pixel is represented by a 32-bit word with B
in the lowest 8 bits, G in the next 8 bits, R in the
8 bits after that and A in the highest 8 bits. */
NV_ENC_BUFFER_FORMAT_ARGB10=0x02000000,/**< 10 bit Packed A2R10G10B10. This is a word-ordered format
where a pixel is represented by a 32-bit word with B
in the lowest 10 bits, G in the next 10 bits, R in the
10 bits after that and A in the highest 2 bits. */
NV_ENC_BUFFER_FORMAT_AYUV=0x04000000,/**< 8 bit Packed A8Y8U8V8. This is a word-ordered format
where a pixel is represented by a 32-bit word with V
in the lowest 8 bits, U in the next 8 bits, Y in the
8 bits after that and A in the highest 8 bits. */
NV_ENC_BUFFER_FORMAT_ABGR=0x10000000,/**< 8 bit Packed A8B8G8R8. This is a word-ordered format
where a pixel is represented by a 32-bit word with R
in the lowest 8 bits, G in the next 8 bits, B in the
8 bits after that and A in the highest 8 bits. */
NV_ENC_BUFFER_FORMAT_ABGR10=0x20000000,/**< 10 bit Packed A2B10G10R10. This is a word-ordered format
where a pixel is represented by a 32-bit word with R
in the lowest 10 bits, G in the next 10 bits, B in the
10 bits after that and A in the highest 2 bits. */
uint32_tversion;/**< [in]: Struct version. Must be set to ::NV_ENC_CREATE_BITSTREAM_BUFFER_VER */
uint32_tsize;/**< [in]: Size of the bitstream buffer to be created */
NV_ENC_MEMORY_HEAPmemoryHeap;/**< [in]: Deprecated. Will be removed in sdk 8.0 */
uint32_tsize;/**< [in]: Deprecated. Do not use */
NV_ENC_MEMORY_HEAPmemoryHeap;/**< [in]: Deprecated. Do not use */
uint32_treserved;/**< [in]: Reserved and must be set to 0 */
NV_ENC_OUTPUT_PTRbitstreamBuffer;/**< [out]: Pointer to the output bitstream buffer */
void*bitstreamBufferPtr;/**< [out]: Reserved and should not be used */
@@ -1073,14 +1108,15 @@ typedef struct _NV_ENC_QP
uint32_tzeroReorderDelay:1;/**< [in]: Set this to 1 to indicate zero latency operation (no reordering delay, num_reorder_frames=0) */
uint32_tenableNonRefP:1;/**< [in]: Set this to 1 to enable automatic insertion of non-reference P-frames (no effect if enablePTD=0) */
uint32_tstrictGOPTarget:1;/**< [in]: Set this to 1 to minimize GOP-to-GOP rate fluctuations */
uint32_taqStrength:4;/**< [in]: When AQ (Spatial) is enabled (i.e. NV_ENC_RC_PARAMS::enableAQ is set), this field is used to specify AQ strength. AQ strength scale is from 1 (low) - 15 (aggressive). If not set, strength is autoselected by driver. Currently supported only with h264 */
uint32_taqStrength:4;/**< [in]: When AQ (Spatial) is enabled (i.e. NV_ENC_RC_PARAMS::enableAQ is set), this field is used to specify AQ strength. AQ strength scale is from 1 (low) - 15 (aggressive). If not set, strength is autoselected by driver. */
uint32_treservedBitFields:16;/**< [in]: Reserved bitfields and must be set to 0 */
NV_ENC_QPminQP;/**< [in]: Specifies the minimum QP used for rate control. Client must set NV_ENC_CONFIG::enableMinQP to 1. */
NV_ENC_QPmaxQP;/**< [in]: Specifies the maximum QP used for rate control. Client must set NV_ENC_CONFIG::enableMaxQP to 1. */
NV_ENC_QPinitialRCQP;/**< [in]: Specifies the initial QP used for rate control. Client must set NV_ENC_CONFIG::enableInitialRCQP to 1. */
uint32_ttemporallayerIdxMask;/**< [in]: Specifies the temporal layers (as a bitmask) whose QPs have changed. Valid max bitmask is [2^NV_ENC_CAPS_NUM_MAX_TEMPORAL_LAYERS - 1] */
uint8_ttemporalLayerQP[8];/**< [in]: Specifies the temporal layer QPs used for rate control. Temporal layer index is used as as the array index */
uint16_ttargetQuality;/**< [in]: Target CQ (Constant Quality) level for VBR mode (range 0-51 with 0-automatic) */
uint8_ttargetQuality;/**< [in]: Target CQ (Constant Quality) level for VBR mode (range 0-51 with 0-automatic) */
uint8_ttargetQualityLSB;/**< [in]: Fractional part of target quality (as 8.8 fixed point format) */
uint16_tlookaheadDepth;/**< [in]: Maximum depth of lookahead with range 0-32 (only used if enableLookahead=1) */
uint32_thierarchicalPFrames:1;/**< [in]: Set to 1 to enable hierarchical PFrames */
uint32_thierarchicalBFrames:1;/**< [in]: Set to 1 to enable hierarchical BFrames */
uint32_toutputBufferingPeriodSEI:1;/**< [in]: Set to 1 to write SEI buffering period syntax in the bitstream */
uint32_toutputPictureTimingSEI:1;/**< [in]: Set to 1 to write SEI picture timing syntax in the bitstream */
uint32_toutputPictureTimingSEI:1;/**< [in]: Set to 1 to write SEI picture timing syntax in the bitstream. When set for following rateControlMode : NV_ENC_PARAMS_RC_CBR, NV_ENC_PARAMS_RC_CBR_LOWDELAY_HQ,
NV_ENC_PARAMS_RC_CBR_HQ, filler data is inserted if needed to achieve hrd bitrate */
uint32_toutputAUD:1;/**< [in]: Set to 1 to write access unit delimiter syntax in bitstream */
uint32_tdisableSPSPPS:1;/**< [in]: Set to 1 to disable writing of Sequence and Picture parameter info in bitstream */
uint32_toutputFramePackingSEI:1;/**< [in]: Set to 1 to enable writing of frame packing arrangement SEI messages to bitstream */
Check support for constrained encoding using ::NV_ENC_CAPS_SUPPORT_CONSTRAINED_ENCODING caps. */
uint32_trepeatSPSPPS:1;/**< [in]: Set to 1 to enable writing of Sequence and Picture parameter for every IDR frame */
uint32_tenableVFR:1;/**< [in]: Set to 1 to enable variable frame rate. */
uint32_tenableLTR:1;/**< [in]: Currently this feature is not available and must be set to 0. Set to 1 to enable LTR support and auto-mark the first */
uint32_tenableLTR:1;/**< [in]: Set to 1 to enable LTR (Long Term Reference) frame support. LTR can be used in two modes: "LTR Trust" mode and "LTR Per Picture" mode.
LTR Trust mode: In this mode, ltrNumFrames pictures after IDR are automatically marked as LTR. This mode is enabled by setting ltrTrustMode = 1.
Use of LTR Trust mode is strongly discouraged as this mode may be deprecated in future.
LTR Per Picture mode: In this mode, client can control whether the current picture should be marked as LTR. Enable this mode by setting
ltrTrustMode = 0 and ltrMarkFrame = 1 for the picture to be marked as LTR. This is the preferred mode
for using LTR.
Note that LTRs are not supported if encoding session is configured with B-frames */
uint32_tqpPrimeYZeroTransformBypassFlag:1;/**< [in]: To enable lossless encode set this to 1, set QP to 0 and RC_mode to NV_ENC_PARAMS_RC_CONSTQP and profile to HIGH_444_PREDICTIVE_PROFILE.
Check support for lossless encoding using ::NV_ENC_CAPS_SUPPORT_LOSSLESS_ENCODE caps. */
uint32_tuseConstrainedIntraPred:1;/**< [in]: Set 1 to enable constrained intra prediction. */
uint32_tseparateColourPlaneFlag;/**< [in]: Set to 1 to enable 4:4:4 separate colour planes */
uint32_tdisableDeblockingFilterIDC;/**< [in]: Specifies the deblocking filter mode. Permissible value range: [0,2] */
uint32_tnumTemporalLayers;/**< [in]: Specifies max temporal layers to be used for hierarchical coding. Valid value range is [1,::NV_ENC_CAPS_NUM_MAX_TEMPORAL_LAYERS] */
uint32_tspsId;/**< [in]: Specifies the SPS id of the sequence header. Currently reserved and must be set to 0. */
uint32_tppsId;/**< [in]: Specifies the PPS id of the picture header. Currently reserved and must be set to 0. */
uint32_tspsId;/**< [in]: Specifies the SPS id of the sequence header */
uint32_tppsId;/**< [in]: Specifies the PPS id of the picture header */
NV_ENC_H264_ADAPTIVE_TRANSFORM_MODEadaptiveTransformMode;/**< [in]: Specifies the AdaptiveTransform Mode. Check support for AdaptiveTransform mode using ::NV_ENC_CAPS_SUPPORT_ADAPTIVE_TRANSFORM caps. */
NV_ENC_H264_FMO_MODEfmoMode;/**< [in]: Specified the FMO Mode. Check support for FMO using ::NV_ENC_CAPS_SUPPORT_FMO caps. */
NV_ENC_H264_BDIRECT_MODEbdirectMode;/**< [in]: Specifies the BDirect mode. Check support for BDirect mode using ::NV_ENC_CAPS_SUPPORT_BDIRECT_MODE caps.*/
uint32_toutputBufferingPeriodSEI:1;/**< [in]: Set 1 to write SEI buffering period syntax in the bitstream */
uint32_toutputPictureTimingSEI:1;/**< [in]: Set 1 to write SEI picture timing syntax in the bitstream */
uint32_toutputAUD:1;/**< [in]: Set 1 to write Access Unit Delimiter syntax. */
uint32_tenableLTR:1;/**< [in]: Set 1 to enable use of long term reference pictures for inter prediction. */
uint32_tenableLTR:1;/**< [in]: Set to 1 to enable LTR (Long Term Reference) frame support. LTR can be used in two modes: "LTR Trust" mode and "LTR Per Picture" mode.
LTR Trust mode: In this mode, ltrNumFrames pictures after IDR are automatically marked as LTR. This mode is enabled by setting ltrTrustMode = 1.
Use of LTR Trust mode is strongly discouraged as this mode may be deprecated in future releases.
LTR Per Picture mode: In this mode, client can control whether the current picture should be marked as LTR. Enable this mode by setting
ltrTrustMode = 0 and ltrMarkFrame = 1 for the picture to be marked as LTR. This is the preferred mode
for using LTR.
Note that LTRs are not supported if encoding session is configured with B-frames */
uint32_tdisableSPSPPS:1;/**< [in]: Set 1 to disable VPS,SPS and PPS signalling in the bitstream. */
uint32_trepeatSPSPPS:1;/**< [in]: Set 1 to output VPS,SPS and PPS for every IDR frame.*/
uint32_tenableIntraRefresh:1;/**< [in]: Set 1 to enable gradual decoder refresh or intra refresh. If the GOP structure uses B frames this will be ignored */
Will be disabled if NV_ENC_CONFIG::gopLength is not set to NVENC_INFINITE_GOPLENGTH. */
uint32_tintraRefreshCnt;/**< [in]: Specifies the length of intra refresh in number of frames for periodic intra refresh. This value should be smaller than intraRefreshPeriod */
uint32_tmaxNumRefFramesInDPB;/**< [in]: Specifies the maximum number of references frames in the DPB.*/
uint32_tltrNumFrames;/**< [in]: Specifies the number of LTR frames used.
If ltrTrustMode=1, encoder will mark first numLTRFrames base layer reference frames within each IDR interval as LTR.
If ltrMarkFrame=1, ltrNumFrames specifies maximum number of ltr frames in DPB.
If ltrNumFrames value is more that DPB size(maxNumRefFramesInDPB) encoder will take decision on its own. */
uint32_tvpsId;/**< [in]: Specifies the VPS id of the video parameter set. Currently reserved and must be set to 0. */
uint32_tspsId;/**< [in]: Specifies the SPS id of the sequence header. Currently reserved and must be set to 0. */
uint32_tppsId;/**< [in]: Specifies the PPS id of the picture header. Currently reserved and must be set to 0. */
uint32_tltrNumFrames;/**< [in]: This parameter has different meaning in two LTR modes.
In "LTR Trust" mode (ltrTrustMode = 1), encoder will mark the first ltrNumFrames base layer reference frames within each IDR interval as LTR.
In "LTR Per Picture" mode (ltrTrustMode = 0 and ltrMarkFrame = 1), ltrNumFrames specifies maximum number of LTR frames in DPB. */
uint32_tvpsId;/**< [in]: Specifies the VPS id of the video parameter set */
uint32_tspsId;/**< [in]: Specifies the SPS id of the sequence header */
uint32_tppsId;/**< [in]: Specifies the PPS id of the picture header */
uint32_tsliceMode;/**< [in]: This parameter in conjunction with sliceModeData specifies the way in which the picture is divided into slices
sliceMode = 0 CTU based slices, sliceMode = 1 Byte based slices, sliceMode = 2 CTU row based slices, sliceMode = 3, numSlices in Picture
When sliceMode == 0 and sliceModeData == 0 whole picture will be coded with one slice */
uint32_tenableExternalMEHints:1;/**< [in]: Set to 1 to enable external ME hints for the current frame. For NV_ENC_INITIALIZE_PARAMS::enablePTD=1 with B frames, programming L1 hints is optional for B frames since Client doesn't know internal GOP structure.
NV_ENC_PIC_PARAMS::meHintRefPicDist should preferably be set with enablePTD=1. */
uint32_tenableMEOnlyMode:1;/**< [in]: Set to 1 to enable ME Only Mode .*/
uint32_treservedBitFields:28;/**< [in]: Reserved bitfields and must be set to 0 */
uint32_tenableWeightedPrediction:1;/**< [in]: Set this to 1 to enable weighted prediction. Not supported if encode session is configured for B-Frames( 'frameIntervalP' in NV_ENC_CONFIG is greater than 1).*/
uint32_treservedBitFields:27;/**< [in]: Reserved bitfields and must be set to 0 */
uint32_tprivDataSize;/**< [in]: Reserved private data buffer size and must be set to 0 */
void*privData;/**< [in]: Reserved private data buffer and must be set to NULL */
NV_ENC_CONFIG*encodeConfig;/**< [in]: Specifies the advanced codec specific structure. If client has sent a valid codec config structure, it will override parameters set by the NV_ENC_INITIALIZE_PARAMS::presetGUID parameter. If set to NULL the NvEncodeAPI interface will use the NV_ENC_INITIALIZE_PARAMS::presetGUID to set the codec specific parameters.
sliceMode = 2, sliceModeData specifies # of MB rows in each slice (except last slice)
sliceMode = 3, sliceModeData specifies number of slices in the picture. Driver will divide picture into slices optimally */
uint32_tltrMarkFrameIdx;/**< [in]: Specifies the long term referenceframe index to use for marking this frame as LTR.*/
uint32_tltrUseFrameBitmap;/**< [in]: Specifies the the associated bitmap of LTR frame indices when encoding this frame. */
uint32_tltrUsageMode;/**< [in]: Specifies additional usage constraints for encoding using LTR frames from this point further. 0: no constraints, 1: no short term refs older than current, no previous LTR frames.*/
uint32_tltrUseFrameBitmap;/**< [in]: Specifies the the associated bitmap of LTR frame indices to use when encoding this frame. */
uint32_tltrUsageMode;/**< [in]: Not supported. Reserved for future use and must be set to 0. */
uint32_treserved[243];/**< [in]: Reserved and must be set to 0. */
void*reserved2[62];/**< [in]: Reserved and must be set to NULL. */
sliceMode = 2, sliceModeData specifies # of CTU rows in each slice (except last slice)
sliceMode = 3, sliceModeData specifies number of slices in the picture. Driver will divide picture into slices optimally */
uint32_tltrMarkFrameIdx;/**< [in]: Specifies the long term reference frame index to use for marking this frame as LTR.*/
uint32_tltrUseFrameBitmap;/**< [in]: Specifies the associated bitmap of LTR frame indices when encoding this frame. */
uint32_tltrUsageMode;/**< [in]: Specifies additional usage constraints for encoding using LTR frames from this point further. 0: no constraints, 1: no short term refs older than current, no previous LTR frames.*/
uint32_tltrUseFrameBitmap;/**< [in]: Specifies the associated bitmap of LTR frame indices to use when encoding this frame. */
uint32_tltrUsageMode;/**< [in]: Not supported. Reserved for future use and must be set to 0. */
uint32_tseiPayloadArrayCnt;/**< [in]: Specifies the number of elements allocated in seiPayloadArray array. */
uint32_treserved;/**< [in]: Reserved and must be set to 0. */
NV_ENC_SEI_PAYLOAD*seiPayloadArray;/**< [in]: Array of SEI payloads which will be inserted for this frame. */
NV_ENC_CODEC_PIC_PARAMScodecPicParams;/**< [in]: Specifies the codec specific per-picture encoding parameters. */
NVENC_EXTERNAL_ME_HINT_COUNTS_PER_BLOCKTYPEmeHintCountsPerBlock[2];/**< [in]: Specifies the number of hint candidates per block per direction for the current frame. meHintCountsPerBlock[0] is for L0 predictors and meHintCountsPerBlock[1] is for L1 predictors.
The candidate count in NV_ENC_PIC_PARAMS::meHintCountsPerBlock[lx] must never exceed NV_ENC_INITIALIZE_PARAMS::maxMEHintCountsPerBlock[lx] provided during encoder intialization. */
NVENC_EXTERNAL_ME_HINT*meExternalHints;/**< [in]: Specifies the pointer to ME external hints for the current frame. The size of ME hint buffer should be equal to number of macroblocks multiplied by the total number of candidates per macroblock.
NVENC_EXTERNAL_ME_HINT*meExternalHints;/**< [in]: Specifies the pointer to ME external hints for the current frame. The size of ME hint buffer should be equal to number of macroblocks * the total number of candidates per macroblock.
The total number of candidates per MB per direction = 1*meHintCountsPerBlock[Lx].numCandsPerBlk16x16 + 2*meHintCountsPerBlock[Lx].numCandsPerBlk16x8 + 2*meHintCountsPerBlock[Lx].numCandsPerBlk8x8
+ 4*meHintCountsPerBlock[Lx].numCandsPerBlk8x8. For frames using bidirectional ME , the total number of candidates for single macroblock is sum of total number of candidates per MB for each direction (L0 and L1) */
uint32_treserved1[6];/**< [in]: Reserved and must be set to 0 */
void*completionEvent;/**< [in]: Specifies an event to be signalled on completion of motion estimation
of this Frame [only if operating in Asynchronous mode].
Each output buffer should be associated with a distinct event pointer. */
uint32_treserved1[252];/**< [in]: Reserved and must be set to 0 */
void*reserved2[60];/**< [in]: Reserved and must be set to NULL */
uint32_tviewID;/**< [in]: Specifies left,right viewID if NV_ENC_CONFIG_H264_MEONLY::bStereoEnable is set.
viewID can be 0,1 if bStereoEnable is set, 0 otherwise. */
NVENC_EXTERNAL_ME_HINT_COUNTS_PER_BLOCKTYPE
meHintCountsPerBlock[2];/**< [in]: Specifies the number of hint candidates per block for the current frame. meHintCountsPerBlock[0] is for L0 predictors.
The candidate count in NV_ENC_PIC_PARAMS::meHintCountsPerBlock[lx] must never exceed NV_ENC_INITIALIZE_PARAMS::maxMEHintCountsPerBlock[lx] provided during encoder intialization. */
NVENC_EXTERNAL_ME_HINT*meExternalHints;/**< [in]: Specifies the pointer to ME external hints for the current frame. The size of ME hint buffer should be equal to number of macroblocks * the total number of candidates per macroblock.
The total number of candidates per MB per direction = 1*meHintCountsPerBlock[Lx].numCandsPerBlk16x16 + 2*meHintCountsPerBlock[Lx].numCandsPerBlk16x8 + 2*meHintCountsPerBlock[Lx].numCandsPerBlk8x8
+ 4*meHintCountsPerBlock[Lx].numCandsPerBlk8x8. For frames using bidirectional ME , the total number of candidates for single macroblock is sum of total number of candidates per MB for each direction (L0 and L1) */
uint32_treserved1[243];/**< [in]: Reserved and must be set to 0 */
void*reserved2[59];/**< [in]: Reserved and must be set to NULL */
uint32_tversion;/**< [in]: Struct version. Must be set to ::NV_ENC_REGISTER_RESOURCE_VER. */
NV_ENC_INPUT_RESOURCE_TYPEresourceType;/**< [in]: Specifies the type of resource to be registered. Supported values are ::NV_ENC_INPUT_RESOURCE_TYPE_DIRECTX, ::NV_ENC_INPUT_RESOURCE_TYPE_CUDADEVICEPTR. */
NV_ENC_INPUT_RESOURCE_TYPEresourceType;/**< [in]: Specifies the type of resource to be registered.
@@ -13,8 +13,9 @@ You can disable all the demuxers using the configure option
the option @code{--enable-demuxer=@var{DEMUXER}}, or disable it
with the option @code{--disable-demuxer=@var{DEMUXER}}.
The option @code{-formats} of the ff* tools will display the list of
enabled demuxers.
The option @code{-demuxers} of the ff* tools will display the list of
enabled demuxers. Use @code{-formats} to view a combined list of
enabled demuxers and muxers.
The description of some of the currently available demuxers follows.
@@ -243,11 +244,17 @@ file subdir/file-2.wav
@end example
@end itemize
@section flv
@section flv, live_flv
Adobe Flash Video Format demuxer.
This demuxer is used to demux FLV files and RTMP network streams.
This demuxer is used to demux FLV files and RTMP network streams. In case of live network streams, if you force format, you may use live_flv option instead of flv to survive timestamp discontinuities.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.