This option is only used by mpegvideoenc, and xvid.
It is a very codec-specific option, so deprecate the global variant.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This option is only used by mpegvideoenc, x264, xavs, and vpx.
It is a very codec-specific option, so deprecate the global variant.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This option is only used by mpegvideoenc, x264, and xavs.
It is a very codec-specific option, so deprecate the global variant.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This option is only used by x264 and xavs.
It is a very codec-specific option, so deprecate the global variant.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
These options are only used by mpegvideoenc and vpx.
They are very codec-specific options, so deprecate the global variants.
Add an allowed value to the private options for frame_skip_cmp which
seems to have been forgotten, but perfectly working.
The libvpx frame dropping feature uses one of such option
(frame_skip_threshold) without the other three. For this reason rename
the option to something more consistent with the other libvpx variables.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This option is only used by mpegvideoenc,
It is a very codec-specific option, so deprecate the global variant.
Set proper limits to the maximum allowed values.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The b_frame_strategy option is only used by mpegvideoenc, qsv, x264, and
xavs, while b_sensitivity is only used by mpegvideoenc.
These are very codec-specific options, so deprecate the global variants.
Set proper limits to the maximum allowed values.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit 'f0b769c16daafa64720dcba7fa81a9f5255e1d29':
lavc: add a packet side data type for VBV-like parameters
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '31c51f7441de07b88cfea2550245bf1f5140cb8f':
avpacket: add a function for wrapping existing data as side data
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
These variables are coming from mpegvideoenc where are supposedly used
as bit counters on various frame properties. However their use is
unclear as they lack documentation, are available only from a very small
subset of encoders, and they are hardly used in the wild. Also frame_bits
in aacenc is employed in a similar way.
Remove this functionality from AVCodecContex, these variable are mostly
frame properties, and too few encoders support setting them with anything
useful.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Most option values are simply unused or ignored and in practice the
majory of codecs only need to check whether to enable rle or not.
Add appropriate codec private options which better expose the allowed
features.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit '79ae1e630b476889c251fc905687a3831b43ab5e':
avcodec: Define side data type for fallback track
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This function returns the encoded data of a frame, one slice at a time
directly when that slice is encoded, instead of waiting for the full
frame to be done. However this field has a debatable usefulness, since
it looks like it is just a convoluted way to get data at lowest
possible latency, or a somewhat hacky way to store h263 in RFC-2190
rtp encapsulation.
Moreover when multi-threading is enabled (which is by default) the order
of returned slices is not deterministic at all, making the use of this
function not reliable at all (or at the very least, more complicated
than it should be).
So, for the reasons stated above, and being used by only a single encoder
family (mpegvideo), this field is deemed unnecessary, overcomplicated,
and not really belonging to libavcodec. Libavformat features a complete
implementation of RFC-2190, for any other case.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This side data type is meant to be added to AVStream side data.
A fallback track indicates an alternate track to use when the
current track can not be decoded for some reason. e.g. no
decoder available for codec.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit 'a9a60106370f862e191dea58e748626da6a8fe97':
avpacket: Provide an alloc and a free function for the struct
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'dca23ffbc7568c9af5c5fbaa86e6a0761ecae50c':
lavc: Deprecate AVPicture structure and related functions
Deprecation flag on AVPicture struct replaced by a comment, as it causes
excess deprecation warnings for every include of avcodec.h
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
This structure served as a bridge between data pointers and frames,
but it suffers from several limitations:
- it is not refcounted and data must be copied to every time
- it cannot be expanded without ABI break due to being used on the stack
- its functions are just wrappers to imgutils which add a layer of
unneeded indirection, and maintenance burden
- it allows hacks like embedding uncompressed data in packets
- its use is often confusing to our users
AVFrame provides a much better API, and, if a full blown frame is not
needed, it is just as simple and more straightfoward to use data and
linesize arrays directly.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Use the new fields directly instead of the ones from AVPicture.
This removes a layer of indirection which serves no pratical purpose
whatsoever, and will help in removing AVPicture structure completely
later.
Every subtitle encoder/decoder seamlessly points to the new arrays,
so it is possible to deprecate AVSubtitleRect.pict.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This commit shall introduce the first step of adding support for the
Daala next generation video codec to FFmpeg. Although still in
development, the codec is showing good progress and exchanging work
through IETF drafts. The companies behind Daala are also participating
in the Alliance for Open Media, so it's likely that whatever the result
any of these collaborations produce it's probable that elements from
Daala could be used in them, or perhaps this codec itself could be the
result.
It was merged with the iff_ilbm decoder in commit
929a24efff.
Define AV_CODEC_ID_IFF_BYTERUN1 as AV_CODEC_ID_IFF_ILBM for API
compatibility.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
* commit '948f3c19a8bd069768ca411212aaf8c1ed96b10d':
lavc: Make AVPacket.duration int64, and deprecate convergence_duration
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Note that convergence_duration had another meaning, one which was in
practice never used. The only real use for it was a 64 bit replacement
for the duration field. It's better just to make duration 64 bits, and
to get rid of it.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
"int" is useful in testing because provides accurate results across
different plaftforms, so remove it from the scheduled FF_API_UNUSED_MEMBERS
deprecation.
Deprecate the now unused option, but temporarily retain the capability
to disable the now default behaviour.
Mention this change in the AVPacket documentation.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Based on a patch by wm4.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '069713aa4b137781e270768d803b1f7456daa724':
lavc: Drop deprecated thread opaque and codec pkt
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '9f90b24877016e7140b9b14e4b1acee663bb6d8a':
lavc: Drop deprecated get_buffer related functions
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '01bcc2d5c23fa757d163530abb396fd02f1be7c8':
lavc: Drop deprecated destruct_packet related functions
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'dc70c19476e76f1118df73b5d97cc76f0e5f6f6c':
lavc: Drop deprecated request_channels related functions
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
The h264 decoder reports 4.1 as its maximum level, but it will decode
5.1 4K video just fine. In practice, the published level limits in
vdpau do not communicate anything that's actually useful.
Avoid duplicating the literal numeric values
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This option is extremely codec specific and only a few codecs employ it.
Move it to codec private options instead: mpegenc family supports only 3
values, xavs and x264 use 5, and xvid has a different metric entirely.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The stats are a superset of the quality factor, also allowing the picture type and encoder "PSNR" stats to be exported
This also replaces the native by fixed little endian order for the affected side data
AV_PKT_DATA_QUALITY_FACTOR is left as a synonym of AV_PKT_DATA_QUALITY_STATS
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '5d3addb937946eca5391e40b5e6308e74ac6f77b':
Add a quality factor packet side data
Conflicts:
doc/APIchanges
ffmpeg.c
libavcodec/avcodec.h
libavcodec/mpegvideo_enc.c
libavcodec/version.h
Merged-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>
This is necessary to preserve the quality information currently exported
with coded_frame. Add the new side data to every encoder that needs it,
and use it in avconv.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
They are used by dnxhd and mpegvideo_enc exclusively, move them to codec
private options instead.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This HWAccel isn't really usable right now due to an nvidia driver bug,
so we don't want it selected by default.
HWAccels have a capabilities field and there's a comment about flags,
but no flags exist today, so let's add one for experimental hwaccels.
* commit '8655c54160767de1a6b96f8bc310d6e4eaceff48':
libvpx: Support the vp9 extended profiles
Conflicts:
Changelog
configure
libavcodec/libvpx.c
libavcodec/libvpx.h
libavcodec/libvpxdec.c
libavcodec/libvpxenc.c
libavcodec/version.h
mostly not merged, as requested by jamrial
See: 01e59d48ed
See: 079b7f6eac and others
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Bump the minimum libvpx version to 1.3.0 and rework the configure logic
to fail only if no decoders and encoders are found.
Based on the original patch from Vittorio.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* commit '9af7e8045e3e63ab39adedae9a7c11b1c410af26':
lavc: Clarify the behaviour of dimension and format context fields
Conflicts:
libavcodec/avcodec.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The AVCodecContext width, height, coded_width, coded_height and format
are used mainly as decoding hints and they get internally overwritten
during the data parsing stage.
Do not assume they match the last AVFrame provided by
avcodec_decode_video2 and assimilated functions since multi-threading
and other frame reordering might make those values to refer to frames
that will be outputted in the future.
CC: libav-stable@libav.org
This field is designed for marking codec properties useful to lavc internals.
Two internal capabilities are added:
- FF_CODEC_CAP_INIT_THREADSAFE: codec can be opened without locks;
- FF_CODEC_CAP_INIT_CLEANUP: codec frees memory if initialization fails.
* commit '31d2039cb42668ebcf08248bc48bbad44aa05f49':
h264_parser: export video format and dimensions
Conflicts:
libavcodec/h264_parser.c
libavcodec/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '728685f37ab333ca35980bd01766c78d197f784a':
Add a side data type for audio service type.
Conflicts:
doc/APIchanges
libavcodec/avcodec.h
libavcodec/version.h
libavutil/frame.h
libavutil/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Move the lavc/imgconvert functions and rename them as follows:
avpicture_get_size -> av_image_get_buffer_size()
avpicture_fill -> av_image_fill_arrays()
avpicture_layout -> av_image_copy_to_buffer()
The new functions have an align parameter, which allows to define the
linesize alignment assumed in the buffer (which is set or read).
The names of the functions are consistent with the lavu/samples API
(av_samples_get_buffer_size(), av_samples_fill_arrays()).
A redundant check has been dropped from av_image_fill_arrays().
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This can be used by the application to signal its ability to cope with
video surface of types other than 8-bits YUV 4:2:0.
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This carries the pixel format that would be used if it were not for
hardware acceleration. This is equal to AVCodecContext.pix_fmt if
hardware acceleration is not in use.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit 'b72727a5248f1ef02db99b378dce1eb48a46357a':
lavc: mention that the parser callback never returns an error
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '530c1441fd1426b6a4bb33485ff3226e1ae0ad45':
lavc: make lmax/lmin into private options of mpegvideo encoders
Conflicts:
libavcodec/avcodec.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '15ec053c4c0b198a2e93eb8e60c8f41e091e0c40':
lavc: make border_masking into private options of mpegvideo encoders
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '66a68ddd1ac376b24db8695058bc8fc28f5bada6':
lavc: make rc_buffer_aggressivity/rc_initial_cplx into private options of mpegvideo encoders
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a75c2eb25a62105c09b48521aef429dc8a231637':
lavc: make rc_eq into private options of mpegvideo encoders
Conflicts:
libavcodec/options_table.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '946f95354ba76ef73c9b66889d86ab5fba4fb486':
lavc: make rc_qmod_* into private options of mpegvideo encoders
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a6e4ce9fd50897dc6d9c2ada4b6b8090de7de5bf':
lavc: make rc_qsquish a private option of mpegvideo encoders
Conflicts:
libavcodec/avcodec.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7ea1b3472a61de4aa4d41b571e99418e4997ad41':
lavc: deprecate the use of AVCodecContext.time_base for decoding
Conflicts:
libavcodec/avcodec.h
libavcodec/h264.c
libavcodec/mpegvideo_parser.c
libavcodec/utils.c
libavcodec/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
When decoding, this field holds the inverse of the framerate that can be
written in the headers for some codecs. Using a field called 'time_base'
for this is very misleading, as there are no timestamps associated with
it. Furthermore, this field is used for a very different purpose during
encoding.
Add a new field, called 'framerate', to replace the use of time_base for
decoding.
Decoding acceleration may work even if the codec level is higher than
the stated limit of the VDPAU driver. Or the problem may be considered
acceptable by the user. This flag allows skipping the codec level
capability checks and proceed with decoding.
Applications should obviously not set this flag by default, but only if
the user explicitly requested this behavior (and presumably knows how
to turn it back off if it fails).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit '2df0c32ea12ddfa72ba88309812bfb13b674130f':
lavc: use a separate field for exporting audio encoder padding
Conflicts:
libavcodec/audio_frame_queue.c
libavcodec/avcodec.h
libavcodec/libvorbisenc.c
libavcodec/utils.c
libavcodec/version.h
libavcodec/wmaenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Currently, the amount of padding inserted at the beginning by some audio
encoders, is exported through AVCodecContext.delay. However
- the term 'delay' is heavily overloaded and can have multiple different
meanings even in the case of audio encoding.
- this field has entirely different meanings, depending on whether the
codec context is used for encoding or decoding (and has yet another
different meaning for video), preventing generic handling of the codec
context.
Therefore, add a new field -- AVCodecContext.initial_padding. It could
conceivably be used for decoding as well at a later point.
The register function now specifies that the user callback should
leave things in the same state that it found them on failure but
that failure to destroy is ignored by the library. The register
function is now explicit about its behavior on failure
(it unregisters the previous callback and destroys all mutex).
Signed-off-by: Manfred Georg <mgeorg@google.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The register function now specifies that the user callback should
leave things in the same state that it found them on failure but
that failure to destroy is ignored by the library. The register
function is now explicit about its behavior on failure
(it unregisters the previous callback and destroys all mutex).
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Add CODEC_FLAG2_SKIP_MANUAL (exposed as "skip_manual"), which makes
the decoder export sample skip information via side data, instead
of applying it automatically. The format of the side data is the
same as AV_PKT_DATA_SKIP_SAMPLES, but since AVPacket and AVFrame
side data constants overlap, AV_FRAME_DATA_SKIP_SAMPLES needs to
be introduced.
This is useful for applications which want to do the timestamp
calculations manually, or which actually want to retrieve the
padding.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'd07ddc93e29a4fdf12cd426953a7ecd5abe5e36d':
avcodec: Fix a doxy comment to refer to the right function
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The reasoning behind this addition is that various third party
applications are interested in getting some motion information out of a
video "for free" when it is available.
It was considered to export other information as well (such as the intra
information about the block, or the quantization) but the structure
might have ended up into a half full-generic, half full of codec
specific cruft. If more information is necessary, it should either be
added in the "flags" field of the AVMotionVector structure, or in
another side-data.
This commit also includes an example exporting them in a CSV stream.
