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>
Japanese DTV uses some non standard extensions in AAC audio.
One example is 'dual mono', which combines two independent
audio into one stereo stream, storing them in left and right channels
respectively. Historically, dual mono audio has been used for
multi-lingual audio, one for local/native language, and another for english,
and usually the "main" (local language) channel should be output without
any user interactions.
The frames of those dual mono audio are allowed to set
ADTS channel_config field to 0, and just contain two SCE's *WITHOUT* PCE,
which is a non standard extension by Japanese DTV standard.
(ref. ARIB STD-B32 PartII 5.2.3)
This patch adds an AVPacket side data, AV_PKT_DATA_JP_DUALMONO,
which indicates that the AVPacket is likely to contain an audio frame
with the above dual mono extension, and has the parameter to specify
the desired channel selection in that case.
It also makes aacdec to detect dual mono and output just the desired
channel when this side data is attached.
Signed-off-by: Akihiro Tsukada <atsukada@users.sourceforge.net>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The cpia video decoder is intended to be used with the v4l2 demuxer.
There are some small changes to the v4l2 demuxer to support the
variable frame length of the format.
Fixes ticket #1537
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The special cases in demuxers and decoders are a mess otherwise (and more
would be needed to support it fully)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
After various discussions, we concluded that, amongst other things,
it made sense to have a separate subrip decoder that did not use
in-band timing information, and rather relied on the ffmpeg level
timing.
As this is 90% the same as the existing srt decoder, it's implemented
in the same file.
Signed-off-by: Philip Langdale <philipl@overt.org>
C++ does not allow to mix different enums, so e.g. code comparing
ACodecID with CodecID would fail to compile with gcc.
This very evil hack should fix this problem.