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>
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>
Recently normalization (av_normalize_sf) of output was added to av_add_sf.
This normalization is used for better precision for small values and the
purpose of this (quite simple) test case is to test difference between double
and softfloat.
The values used are tailored to maximally highlighte problem with precison when
normalization is not used.
Signed-off-by: Nedeljko Babic <nedeljko.babic@imgtec.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>
Added in 361702660d. Modified version that
doesn't use this label merged in 55231323b0,
thus obsoleting this label.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fix crash when doing 8 ch conversion from apps compiled with MSVS
Thanks to Ronald for giving this hint:
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-May/173049.html
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3b5e5e6a29d62462d0505287042fa4c2b99c4f2b':
libx265: Use the Multi-library Interface
See: 94c20de429
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This fixes a memleak if read_kuki_chunk is executed more than once.
Reviewed-by: Carl Eugen Hoyos <cehoyos@ag.or.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
If avio_read fails, the buffer can contain uninitialized values.
Reviewed-by: Carl Eugen Hoyos <cehoyos@ag.or.at>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
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>
