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...
