Since lavfi works natively with AVFrame now, these functions are no longer
necessary and can be removed in a future bump.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
more than 8 channels is not supported and crashes with null pointer dereference
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This commit introduces a new AVPacket side data type:
AV_PKT_DATA_STRINGS_METADATA. Its main goal is to provide a way to
transmit the metadata from the AVFilterBufferRef up to the AVFrame. This
is at the moment "only" useful for lavfi input from libavdevice:
lavd/lavfi only outputs packets, and the metadata from the buffer ref
kept in its context needs to be transmitted from the packet to the frame
by the decoders. The buffer ref can be destroyed at any time (along with
the metadata), and a duplication of the AVPacket needs to duplicate the
metadata as well, so the choice of using the side data to store them was
selected.
Making sure lavd/lavfi raises the metadata is useful to allow tools like
ffprobe to access the filters metadata (it is at the moment the only
way); ffprobe will now automatically show the AVFrame metadata in any
customizable output format for users. API users will also be able to
access the AVFrame->metadata pointer the same way ffprobe does
(av_frame_get_metadata).
All the changes are done in this single commit to avoid some memory
leaks: for instances, the changes in lavfi/avcodec.c are meant to
duplicate the metadata from the buffer ref into the AVFrame. Unless we
have an internal way of freeing the AVFrame->metadata automatically, it
will leak in most of the user apps. To fix this problem, we introduce
AVCodecContext->metadata and link avctx->metadata to the current
frame->metadata and free it at each decode frame call (and in the codec
closing callback for the last one). But doing this also means to update
the way the tiff decoder already handles the AVFrame->metadata (it's the
only one decoder with frame metadata at the moment), by making sure it
is not trying to free a pointer already freed by the lavc internals.
The lavfi/avcodec.c buffer ref code is based on an old Thomas Kühnel
work, the rest of the code belongs to the commit author.
Signed-off-by: Thomas Kühnel <kuehnelth@googlemail.com>
Signed-off-by: Clément Bœsch <ubitux@gmail.com>
Deprecate functions:
avfilter_fill_frame_from_buffer_ref
avfilter_fill_frame_from_audio_buffer_ref
avfilter_fill_frame_from_video_buffer_ref
and schedule to drop them at the next API major bump.
The function avfilter_copy_buf_props() should be used instead.
Use av_frame_* accessors for the newly added fields in AVFrame (for which
we are supposed to use such accessors), and group the istructions
accordingly.
The function will abort through an assert if the source is not defined,
or if the internal state of the source is inconsistent (e.g. type = AUDIO
&& !src->audio).
avcodec.c is where it is defined the lavc/lavfi interface code, so seems
a more adequate location (and doesn't force the inclusion of
libavcodec/avcodec.h where it is not required).
git blame:
45 Stefano Sabatini
23 Clément Bœsch
4 Michael Niedermayer
3 Robert Nagy
3 Nicolas George
2 Roger Pau Monné
Initial commit:
commit 566666caf3
Author: Stefano Sabatini <stefano.sabatini-lala@poste.it>
Date: Sun May 1 14:47:05 2011 +0200
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
avfilter_copy_frame_props() avoids code duplication and increases
robustness.
The added files libavfilter/avcodec.[ch] are used for containing
utilities useful for gluing togheter libavfilter and libavcodec.
Passing an explicit filename to this command is only necessary if the
documentation in the @file block refers to a file different from the
one the block resides in.
Originally committed as revision 22921 to svn://svn.ffmpeg.org/ffmpeg/trunk
Otherwise doxygen complains about ambiguous filenames when files exist
under the same name in different subdirectories.
Originally committed as revision 16912 to svn://svn.ffmpeg.org/ffmpeg/trunk
Consistently apply this rule: the guard name is obtained from the
filename by stripping the leading "lib", converting '/' and '.' to
'_' and uppercasing the resulting name. Guard names in the root
directory have to be prefixed by "FFMPEG_".
Originally committed as revision 15120 to svn://svn.ffmpeg.org/ffmpeg/trunk