Function allows to create string containing object's serialized options.
Such string may be passed back to av_set_options_string() in order to restore options.
Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
This is the same logic as is invoked on AVFMT_TS_NEGATIVE,
but which can be enabled manually, or can be enabled
in muxers which only need it in certain conditions.
Also allow using the same mechanism to force streams to start
at 0.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '5e80fb7ff226f136dbcf3fed00a2966bf8e9bd70':
lavc: add a public API for parsing vorbis packets.
Conflicts:
doc/APIchanges
libavcodec/Makefile
libavcodec/version.h
libavcodec/vorbis_parser.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Since av_gettime() is used in a number of places where actual
real time clock is required, the monotonic clock introduced in
ebef9f5a5 would have consequences that are hard to handle. Instead
split it into a separate function that can be used in the cases
where only relative time is desired.
On platform where no monotonic clock is available, the difference
between the two av_gettime functions is not clear, and one could
mistakenly use the relative clock where an absolute one is
required. Therefore add an offset, to make it evident that the
time returned from av_gettime_relative never is actual current
real time, even though it is based on av_gettime.
Based on a patch by Olivier Langlois.
Signed-off-by: Martin Storsjö <martin@martin.st>
* 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.
This function provides an explicit VDPAU device and VDPAU driver to
libavcodec, so that the application is relieved from codec specifics
and VdpDevice life cycle management.
A stub flags parameter is added for future extension. For instance, it
could be used to ignore codec level capabilities (if someone feels
dangerous).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
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 'b263f8ffe7599d9cd27ec477a12700da8eb2790d':
lavf: add AVFormatContext.max_ts_probe
Conflicts:
doc/APIchanges
libavformat/avformat.h
libavformat/utils.c
libavformat/version.h
lavf-fate/mp3 changes as the estimated input bitrate changes and that is
copied to the output
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '6ca11f7157d0ffd11ea9a4211b04981b46dc75d6':
doc/APIchanges: fill in missing hashes and dates
Conflicts:
doc/APIchanges
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Unfortunately this was not explicitly documented and thus
might be risky.
But all uses I could find in FFmpeg and one in VLC had a memleak
in these cases, and I could not find any that relied on the previous
behaviour.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
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.
Based on commit fb1ddcdc8f by Luca Barbato <lu_zero@gentoo.org>
Adapted for libswresample by Michael Niedermayer
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This allows getting rid of the many, slightly differing, implementations
of basically the same thing.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
