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>
