This will be used to allow writing file sequences using the tee output onto
multiple places in parallel
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'e47b8bbf0b54599d44b9330eb4d68cdde4f6d298':
avcodec: Bump micro version after changing public JPEG 2000 defines
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'db7968bff4851c2be79b15b2cb2ae747424d2fca':
avio: Allow custom IO users to get labels for the output bytestream
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
* commit '0c4468dc185fa8b9e7d6add914595c5e928b24fd':
stereo3d: Add API to get name from value or value from name
Merged-by: Clément Bœsch <clement@stupeflix.com>
This allows callers with avio write callbacks to get the bytestream
positions that correspond to keyframes, suitable for live streaming.
In the simplest form, a caller could expect that a header is written
to the bytestream during the avformat_write_header, and the data
output to the avio context during e.g. av_write_frame corresponds
exactly to the current packet passed in.
When combined with av_interleaved_write_frame, and with muxers that
do buffering (most muxers that do some sort of fragmenting or
clustering), the mapping from input data to bytestream positions
is nontrivial.
This allows callers to get directly information about what part
of the bytestream is what, without having to resort to assumptions
about the muxer behaviour.
One keyframe/fragment/block can still be split into multiple (if
they are larger than the aviocontext buffer), which would call
the callback with e.g. AVIO_DATA_MARKER_SYNC_POINT, followed by
AVIO_DATA_MARKER_UNKNOWN for the second time it is called with
the following data.
Signed-off-by: Martin Storsjö <martin@martin.st>
The new function behaves the same as av_log_format_line, but also forwards
the return value from the underlying snprintf call. This will allow
callers to accurately determine the size requirements for the line buffer.
Signed-off-by: Andreas Weis <github@ghulbus-inc.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.
This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the packet and may produce output, the new API requires the user
to send input first, and then ask for output.
For now, there are no codecs supporting this API. The API can work with
codecs using the old API, and most code added here is to make them
interoperate. The reverse is not possible, although for audio it might.
From Libav commit 05f66706d1.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit '3e8fd93b6ab219221e17fa2b6243cc72cf2d69dc':
lavf: add a missing bump and APIchanges for the codecpar switch
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit 'a8068346e48e123f8d3bdf4d64464d81e53e5fc7':
lavc: add a variant of av_get_audio_frame_duration working with AVCodecParameters
Fixes from jamrial incorporated.
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '998e1b8f521b73e1ed3a13caaabcf79eb401cf0d':
lavc: add codec parameters API
Fixes added in:
- bit_rate has been made int64_t to match.
- profile and level are properly initialize.
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.
This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the packet and may produce output, the new API requires the user
to send input first, and then ask for output.
For now, there are no codecs supporting this API. The API can work with
codecs using the old API, and most code added here is to make them
interoperate. The reverse is not possible, although for audio it might.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
