Otherwise it will never be reset, and remain "stuck" in this state
forever. Can happen when seeking: the decoder will receive fragments
from different file positions, which triggers the condition easily.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This patch modifies H264 loopfilter, weighted & bi-weighted prediction MIPS-SIMD optimized code according to improved version of generic macros.
Also there are minor code alignment changes.
Overall, this patch is just upgrading the code with styling changes and will bring it in sync with MIPS-SIMD optimized latest codebase at our end.
Signed-off-by: Shivraj Patil <shivraj.patil@imgtec.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit 599888a480.
The commit does not silence the warning on ELF-based systems, and will be
fixed in the subsequent commit.
Conflicts:
libavcodec/x86/fft_mmx.asm
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
h264.h and hevc.h are mutually exclusive due to defining some of the same
names. As such, we need to avoid forcing h264.h to be included if we want
hevc decode acceleration to be possible.
However, some of the pre-hwaccel helper functions need h264.h. To avoid
messy collisions, let's move the declaration of all those helpers to
a separate header which we will exclude for the hevc support (which will
be hwaccel-only).
Signed-off-by: Philip Langdale <philipl@overt.org>
shine_encode_buffer expects written to be an int pointer, while the
previous shine_encode_frame expected it to be a long pointer.
Thus encoding with libshine currently always fails with
"internal buffer too small", because a negative return value of
shine_encode_buffer is interpreted as a very large long value.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This avoids the need to dereference MpegEncContext->pb if it is
already available outside h263p_encode_umotion()
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This avoids the need to dereference MpegEncContext->pb if it is
already available outside ff_h263_encode_motion()
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
WebPAnimEncoder API is a combination of encoder (WebPEncoder) and muxer
(WebPMux). It performs several optimizations to make it more efficient
than the combination of WebPEncode() and native ffmpeg muxer.
When WebPAnimEncoder API is used:
- In the encoder layer: we use WebPAnimEncoderAdd() instead of
WebPEncode().
- The muxer layer: works like a raw muxer.
On the other hand, when WebPAnimEncoder API isn't available, the old code is
used as it is:
- In the codec layer: WebPEncode is used to encode each frame
- In the muxer layer: ffmpeg muxer is used
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '4e17946f10d39eec6cc03fb249ae8147373141b6':
mpegvideo: Rework various functions not to use MpegEncContext directly
Conflicts:
libavcodec/mpegvideo.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a3f4c930ac3f49f47b6e6ffda925d0dcf80320e2':
mpegvideo: Have ff_mpeg_ref_picture use AVCodecContext directly
Conflicts:
libavcodec/mpegvideo.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'd528045558825f01472e9bee873f60c98d661e53':
mpegvideo: Have ff_mpeg_unref_picture use AVCodecContext directly
Conflicts:
libavcodec/mpegvideo.c
libavcodec/mpegvideo_enc.c
The memset is left in place
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This is the 2nd patch in preparation for using WebPAnimEncoder API for encoding
and muxing WebP images.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* cehoyos/master:
lavc/qdrw: Do not fail decoding valid Quickdraw images.
lavf/mov: Use AVCOL_SPC constants when checking color_space.
lavf/mov: Write colour matrix "6" for color_space bt470bg.
lavf/mkv: Only skip prores header if the packet is large enough.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Personally, I need the decoder to back out if get_format() returns no
usable pixel format. This didn't work because the error code was not
propagated down the call chain. This in turn happened because the
variable declaration removed in this patch shadowed the variable, whose
value is returned at the end of the function. Consequently, failures of
decode_nal_unit() were ignored in this place.
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Some clients incorrectly set 24 as bits_per_coded_sample, while
the actual value is preserved in one of the codec headers.
In order to work around this, delay the check until decode_frame().
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This significantly reduces the amount of stack space needed and
also permits to simply copy the rice context again without speed
penalty
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Some files benefit by about 0.3% from this, and speedwise its ok
other files do not benefit and encode to the same size
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Without this change, if you link with an 8bit libx265 and try to specify
a 10bit input color space via:
ffmpeg -i in.mov -c:v libx265 -pix_fmt yuv420p10le out.mp4
It will error with:
Incompatible pixel format 'yuv420p10le' for codec 'libx265',
auto-selecting format 'yuv420p'
With this fix, it will learn if a 10bit libx265 is available at startup,
and thus allow 10bit input color spaces.
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* rbultje/vp9-bugfixes:
vp9: match another find_ref_mvs() bug in libvpx.
vp9: fix scaled motion vector clipping for sub8x8 blocks.
vp9: improve signbias check.
vp9: don't allow compound references if error_resilience is enabled.
vp9: clamp segmented lflvl before applying ref/mode deltas.
vp9: reset loopfilter mode/ref deltas on keyframe.
vp9: fix crash when playing back 440/440 content with width%64<56.
vp9: extend loopfilter workaround for vp9 h/v mix-up to work for 422.
vp9: clip motion vectors in the same way as libvpx does.
vp9: set skip flag if the block had no coded coefficients.
vp9: apply mv scaling workaround only when subsampling is enabled.
vp9: read all 4x4 blocks in sub8x8 blocks individually with scalability.
vp9: fix segmentation map referencing upon framesize change.
vp9: disable more pmulhrsw optimizations in idct16/32.
vp9: disable all pmulhrsw in 8/16 iadst x86 optimizations.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
If we find a second non-sub8x8 motion vector for a non-first sub8x8
block, and the clamped value is identical to the first non-sub8x8
motion vector, then the resulting nearmv motion vector is forced to
zero.
libvpx (probably accidentally) clears the bits if error_res is set,
along with keyframe/intraonly. This probably wasn't the intention
(since it's local data), but it's behaviour we have to copy...
Makes no real difference, but maybe scares coverity less (CID1297578)
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The practical effect of this is that the scaling will wrongly not be
applied to the interpolation edge (the 3/4 constants in this patch).
In other words, we clip to the pre-scaling interpolation, even though
these should be clipped post-scaling. The resulting out-of-frame MVs
are thus automatically clipped within the visible portion of the frame,
which is probably not the intention, but is unfortunately what libvpx
does, so we need to copy that behaviour.
This reproduces libvpx behaviour. It seems like it originally only
targeted loopfilter behaviour, but this unfortunately effects following
block contexting and thus directs bitstream sync.
Fixes CID1271788
with this change the value is more explicitly checked, it was fully checked
before though
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Personally, I need the decoder to back out if get_format() returns no
usable pixel format. This didn't work because the error code was not
propagated down the call chain. This in turn happened because the
variable declaration removed in this patch shadowed the variable, whose
value is returned at the end of the function. Consequently, failures of
decode_nal_unit() were ignored in this place.
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The new code only asks for version 1 if its actually version 1 and
prints the version bytes if its something else
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The positioning was completely wrong. First, the coordinates are
expressed in ASS playback resolution (which is by default 384x288).
Secondly, the coordinates define a drawing rectangle, not a moving area.
The previous code was making subtitles move from a random position to
another random position.
Here we rescale assuming the video resolution is a DVD one (720x480). We
can't really do anything better so far, but since this positioning
information is often from a DVD rip we can consider them relatively
safe.
We got defective video when use GCC 4.9.2 instead of GCC 4.9.1 to compile FFMEPG. And further found
that GCC 4.8 and 4.9 need patch to fix the lvsl/lvsr bug on POWER LE, and GCC 5.1 contains
the correct code since its release. The message on gcc-patches requesting approval for lvsl/lvsr
patch is at https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00228.html.
The fixed code avoids using lvsl and will not depends on GCC version, also it uses less instructions on POWER LE.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is useful for client programs to ask for nv12 surfaces instead of the
current default (uyvy), since those are more efficient to decode to.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Use the Multi-library interface to load at runtime x265 libraries
supporting alternative bit depths (e.g. 8bit and 16bit).
The linked library will try to load the library supporting the
pixel format if it is not supported by itself.
Fallback requesting the native library (passing 0 to x265_api_get) if
a library supporting the requested bit depth is not available.
Signed-off-by: Gopu Govindaswamy <gopu@multicorewareinc.com>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
got_frame_ptr is set again after the if block.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Since commit 676a395a aac->frame->data is not necessarily allocated at
the end of aac_decode_frame_int if avctx->channels is 0.
In this case a bogus frame without any data, but non-zero nb_samples is
returned.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The header had a wrong version description.
Bug-Id: 808
Signed-off-by: Shiina Hideaki <shiina@yndrd.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The previous version checked for 14-bit streams and did not properly
work across buffer boundaries.
Use the 64-bit parser state to make extended sync word detection work
across buffer boundary and check the extended sync word for 16-bit LE
and BE core streams to reduce probability of alias sync detection.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
ffmpeg can now use the x265 multi-library interface to make a runtime
selection between a number of libx265 libraries (perhaps 8bpp and 16bpp).
ffmpeg will link to one build of libx265 (statically or
dynamically) and this linked version of libx265 will support one
bit-depth (8 or 10 bits). At runtime, ffmpeg now has the option to request the
encoder to use a different bit depth(8 or 10). If the requested bitdepth
is zero, or if it matches the bitdepth of the system default libx265 (the
currently linked library), then this library will be used for encode.
If ffmpeg requests a different bit-depth, the linked libx265 will attempt
to dynamically bind a shared library with the requested bit-depth from the install
location (default or user-specified).
new x265 API:
const x265_api* api = x265_api_get(int bitDepth);
x265_api - holds the libx265 public API functions
bitDepth - requested API for 8bpp or 16bpp
note: Use 0 to indicate native bit depth of the linked libx265 and
x265_api_get(0) is guaranteed to return a non-null pointer
Signed-off-by: Gopu Govindaswamy <gopu@multicorewareinc.com>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit 'b9f7a677083647d85e583d6d7384938766a293d7':
png: Set the color range as full range
Conflicts:
libavcodec/pngdec.c
See: 72e7553125
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '243e8443cd9e83c887e3f5edf09a169e7783d14e':
alac: Reject rice_limit 0 if compression is used
Conflicts:
libavcodec/alac.c
See: 4b657a1b1e
Merged-by: Michael Niedermayer <michaelni@gmx.at>
No real difference in quality, its a bit slower for the same dia_size as more
vectors are searched for the same dia_size
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If in compression mode rice_limit = 0 leads to call
`show_bits(gb, k)` in `decode_scalar` with k = 0.
Request a sample in case it is valid and it should be accepted.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
CC: libav-stable@libav.org
The decode_array_0000 assumed that 64 is the minimal block size
while it is not.
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
AV_PIX_FMT_GRAY8/16 are considered YUV formats, and the color_range is
not set - so the API user will have to assume limitted range. (Unless
the API user adds a special-case for the PNG decoder.)
Just export the correct range - full range.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Image dimensions were rounded down causing rows to wrap early if dimensions were not a multiple of 4.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '34efb8a169e4551326e069be47125c6c2cb7ab90':
quickdraw: Support direct pixel blocks
Conflicts:
Changelog
libavcodec/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
In init_planes p->xblen and p->yblen are set to:
p->xblen = s->plane[0].xblen >> s->chroma_x_shift;
p->yblen = s->plane[0].yblen >> s->chroma_y_shift;
These are later used as block_w and block_h arguments of
s->vdsp.emulated_edge_mc. If one of them is 0 it triggers an av_assert2
in emulated_edge_mc:
av_assert2(start_x < end_x && block_w > 0);
av_assert2(start_y < end_y && block_h > 0);
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Quickdraw packs data as a series of codes that the application is supposed
to handle, but it does not define any order in which they might appear.
Since it's unfeasible to support *all* opcodes defined by the spec,
only handle well-known blocks containing video data and ignore any unknown
or unsupported ones.
Move palette loading and rle decoding to separate functions to resue them
in other blocks and drop format initialization in init since it can
support more formats than pal8.
Validate width and height.
previously various variables had a too small type to support the required 32bit unsigned
range allowed from the spec
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
s->ref_pics[i] is later used as ref argument of interpolate_refplane,
where it is dereferenced.
If it is NULL, it causes a segmentation fault.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If bytes is large enough, bytes*8 can overflow and become negative.
In that case 'bufsize -= bytes*8' causes bufsize to increase instead of
decrease.
This leads to a segmentation fault.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
buf_idx + data_unit_size can overflow, causing the '> buf_size' check to
wrongly fail.
This causes a segmentation fault.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
For max_order = 0 the clipping range is invalid. (amin = 2, amax = 1)
CC: libav-stable@libav.org
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Also change the type of begin, end and smp to ptrdiff_t to make the
comparison well-defined.
CC: libav-stable@libav.org
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The minimum of the ath(x, ATH_ADD) function depends on ATH_ADD.
This patch uses the first order approximation to determine it.
For ATH_ADD = 4 this results in the value at 3407.06812 (-5.24241638)
not the one at 3410 (-5.24237967).
CC: libav-stabl@libav.org
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
avctx->bits_per_raw_sample is used in get_sbits_long, which only
supports up to 32 bits.
CC: libav-stable@libav.org
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
AV_PIX_FMT_MONOBLACK has the AV_PIX_FMT_FLAG_BITSTREAM flag, i.e.
linesize can be smaller than width.
Since x_offset is only check against the width, this can lead to
x_offset * bpp >= image_linesize.
In this case ptr could be set to a position outside the image_buf in
png_handle_row, leading to memory corruption and thus crashes.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
During the loop ret can get changed. Since it is not set on all failure
paths, decode_frame_common can return 0 even though an error occurred.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This check was removed in commit 08aec6f6, but
s->last_picture.f->data[0] is still used in handle_p_frame_apng
unconditionally.
This fixes a segmentation fault.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
