Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.
Explicitly mark AVCodec entries that are hardware decoders or most
likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
API users listing hardware decoders in a more generic way. The proposed
AVCodecHWConfig does not provide this information fully, because it's
concerned with decoder configuration, not information about the fact
whether the hardware is used or not.
AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
implementations in case the hardware is not capable.
Based on a patch by Philip Langdale <philipl@overt.org>.
Merges Libav commit 47687a2f8a.
Explicitly identify decoder/encoder wrappers with a common name. This
saves API users from guessing by the name suffix. For example, they
don't have to guess that "h264_qsv" is the h264 QSV implementation, and
instead they can just check the AVCodec .codec and .wrapper_name fields.
Explicitly mark AVCodec entries that are hardware decoders or most
likely hardware decoders with new AV_CODEC_CAPs. The purpose is allowing
API users listing hardware decoders in a more generic way. The proposed
AVCodecHWConfig does not provide this information fully, because it's
concerned with decoder configuration, not information about the fact
whether the hardware is used or not.
AV_CODEC_CAP_HYBRID exists specifically for QSV, which can have software
implementations in case the hardware is not capable.
Based on a patch by Philip Langdale <philipl@overt.org>.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Adds call to x265_param_apply_profile after x265_param_parse.
Added as private option since HEVC profiles other than
Main, Main 10 and MSP in AVCodecContext are consolidated in a single
constant.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Reviewed-by: Lou Logan <lou@lrcd.com>
ff_alloc_packet have been deprecated, switch to use
ff_alloc_packet2.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is in the same the same vein as 380146924e.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
This is in the same the same vein as c981b1145a.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The configure detection is bumped to X265_BUILD >= 68,
since API version 68 corresponds with the x265 1.8
release tarball. The warnings inside x265 about
12-bit being experimental were removed prior to API
version 72 a short time later. At this time of
writing, X265_BUILD is at version 80.
12-bit support in the HEVC standard was approved in
October 2014 as part of HEVC Version 2 and published
in January 2015:
http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=12296http://www.itu.int/rec/T-REC-H.265-201410-Shttps://hevc.hhi.fraunhofer.de/rext
Reveiwed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The rationale is that coded_frame was only used to communicate key_frame,
pict_type and quality to the caller, as well as a few other random fields,
in a non predictable, let alone consistent way.
There was agreement that there was no use case for coded_frame, as it is
a full-sized AVFrame container used for just 2-3 int-sized properties,
which shouldn't even belong into the AVCodecContext in the first place.
The appropriate AVPacket flag can be used instead of key_frame, while
quality is exported with the new AVPacketSideData quality factor.
There is no replacement for the other fields as they were unreliable,
mishandled or just not used at all.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Allocating coded_frame is what most encoders do anyway, so it makes
sense to always allocate and free it in a single place. Moreover a lot
of encoders freed the frame with av_freep() instead of the correct API
av_frame_free().
This bring uniformity to encoder behaviour and prevents applications
from erroneusly accessing this field when not allocated. Additionally
this helps isolating encoders that export information with coded_frame,
and heavily simplifies its deprecation.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
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>
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>
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>
This is similar to what is done in libx264.c
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This allows proper muxing and seeking in things like MPEG-TS, by
placing headers by random access points.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Rodger Combs
wm4
John Stebbins
Gyan Doshi
Jun Zhao
Carl Eugen Hoyos
Derek Buitenhuis
Stephen Hutchinson
Vittorio Giovara
Steve Borho
Gopu Govindaswamy
Luca Barbato
James Almer
Michael Niedermayer
Marcus Gustafsson