Example of non-mappable file is /dev/stdin. Previously passing it as
graph_file value returned error.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
MSVC does not allow passing file pointers between libs
This API can thus not work with MSVC and as it was very recently added
and its it was in no release its removial should not cause any problems
A better API will be implemented, but its not finished yet, this revert is
to avoid potentially blocking the release
Found-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Add function avfilter_graph_parse_ptr() and favor it in place of
avfilter_graph_parse(), which will be restored with the old/Libav
signature at the next bump.
If HAVE_INCOMPATIBLE_LIBAV_API is enabled it will use the
Libav-compatible signature for avfilter_graph_parse().
At the next major bump the current implementation of
avfilter_graph_parse() should be dropped in favor of the Libav/old
implementation.
Should address trac ticket #2672.
This ensures that fps and other values are estimated correctly,
the probesize also is intended to limit disk/protocol reads which
does not apply to lavfi inputs at all.
Fixes Ticket1051
Something similar could be usefull to other input devices
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Allow to specify a filename where to put the filtergraph description.
This is useful to override limitations or glitches of particular shell
environments, and allows a level of indirection for specifying
filtergraphs.
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>
Previously the device was returning EOF when the first sink was ending,
with the current change the device will continue to return frames until
all the sinks are EOF, which seems the most expected behavior.
The list was set to avfilter_all_channel_layouts,
which is really all common channel layouts.
Not setting it leaves an empty list,
which now means really all.
The planar/packed switch and the packing_formats list is no longer
required, since the planar/packed information is now stored in the sample
format enum.
This is technically a major API break, possibly it should be not too
painful as we marked the audio filtering API as unstable.
This is done in order to clarify the non-video-specific nature of the
buffersink code, as the result of the video/audio API unification of
the previous commit, and for improving overall consistency.
