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>
Fix warning when compiling boxblur.
While this is technically a major API break, practically there will be no
one using that function since the filtering API is mostly private, so
that function alone is not usable.
There are several reasons for doing that:
1. It documents the code for the reader and helps find
inconsistencies and bugs.
2. For rej_perms, it guarantees the change will be done
even if the output reference can be created by several
code paths.
3. It can be used to predict cases where a copy will,
or will not happen and optimize buffer allocation
(for example not request a rare direct-rendering buffer
from a device sink if it will be copied anyway).
Note that a filter is still allowed to manage the permissions
on its own without using these fields.
The code currently use cur_buf as the target of the copy,
but cur_buf can be cleared by the filter if it has given
the reference away or stored it elsewhere as soon as start_frame.
The code still relies on the fact that the reference is not
destroyed until end_frame. All filters currently follow that condition.
An av_assert1() is added to check it; it should at least cause
very visible errors in valgrind.
This will be used by filters which require an opaque field to be passed
in input. Should be required only for filters which imply a programmatic
use.
This is possibly a temporary solution, to be removed when we'll have a
clearer and better agreememnt of how/if to pass binary data for
initializing a filter.
See thread:
Subject: [FFmpeg-devel][PATCH] lavfi: add init2 callback
Date: Fri, 6 Jul 2012 01:22:17 +0200
It is not used in any filters currently and is inherently evil. If
passing binary data to filters is required in the future, it should be
done with some AVOptions-based system.
libavfilter API was designed in order to be clarly distinguished from the
libavcodec API, including avcodec.h in avfilter.h is not going to help to
stick to this principle.
The inclusion of libavutil/audioconvert.h in many files was required
because avcodec.h includes audioconvert.h.
libavfilter/avcodec.h is where the lavc/lavfi interface should be
entirely placed.