Currently, AVStream contains an embedded AVCodecContext instance, which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.
In addition, it is also widely used by the callers as the decoding (when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.
There are multiple important problems with this approach:
- the fields in AVCodecContext are in general one of
* stream parameters
* codec options
* codec state
However, it's not clear which ones are which. It is consequently
unclear which fields are a demuxer allowed to set or a muxer allowed to
read. This leads to erratic behaviour depending on whether decoding or
encoding is being performed or not (and whether it uses the AVStream
embedded codec context).
- various synchronization issues arising from the fact that the same
context is used by several different APIs (muxers/demuxers,
parsers, bitstream filters and encoders/decoders) simultaneously, with
there being no clear rules for who can modify what and the different
processes being typically delayed with respect to each other.
- avformat_find_stream_info() making it necessary to support opening
and closing a single codec context multiple times, thus
complicating the semantics of freeing various allocated objects in the
codec context.
Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores only
the stream parameters exported by the demuxers or read by the muxers.
The plain VP6 format is vertically flipped compared to VP6F/VP6A.
Support for the plain VP6 format was added in 09d8c0ae83 (which
also introduced support for muxing VP6F properly in general).
Signed-off-by: Martin Storsjö <martin@martin.st>
Since 596e5d4783, this is not necessary anymore. It also allows to
actually disable the flushing, improving write performance (but
possibly giving worse latency in real-time streaming).
Signed-off-by: Martin Storsjö <martin@martin.st>
The FLV muxer tries to update the header in write_trailer, which is
impossible if writing to a pipe or network stream. Don't write header
data if seeking to the header fails.
Signed-off-by: Martin Storsjö <martin@martin.st>
The compiler fails to figure out that enc->codec_type can only
have 3 different values.
Thus when an if/else is encountered it triggers on the possibility
of the else case has not initialized the flags variable.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
According to its description, it is supposed to be the LCM of all the
frame durations. The usability of such a thing is vanishingly small,
especially since we cannot determine it with any amount of reliability.
Therefore get rid of it after the next bump.
Replace it with the average framerate where it makes sense.
FATE results for the wtv and xmv demux tests change. In the wtv case
this is caused by the file being corrupted (or possibly badly cut) and
containing invalid timestamps. This results in lavf estimating the
framerate wrong and making up wrong frame durations.
In the xmv case the file contains pts jumps, so again the estimated
framerate is far from anything sane and lavf again makes up different
frame durations.
In some other tests lavf starts making up frame durations from different
frame.
Also add missing trailing commas, break long codec_tag lines and
add spaces in codec_tag declarations.
Signed-off-by: Martin Storsjö <martin@martin.st>
The existing functions defined in intfloat_readwrite.[ch] are
both slow and incorrect (infinities are not handled).
This introduces a new header with fast, inline conversion
functions using direct union punning assuming an IEEE-754
system, an assumption already made throughout the code.
The one use of Intel/Motorola extended 80-bit format is
replaced by simpler code sufficient under the present
constraints (positive normal values).
The old functions are marked deprecated and retained for
compatibility.
Signed-off-by: Mans Rullgard <mans@mansr.com>
No application rely on this count being correct as far as
I know, but if we write a nonzero count value, it might just
as well be the right one.
Signed-off-by: Martin Storsjö <martin@martin.st>
Metadata currently is written only at the start of the file in normal
cases, when transcoding from a rtmp source metadata could be
written later and the offset recorded can exceed 32bit.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
In the name of consistency:
put_byte -> avio_w8
put_<type> -> avio_w<type>
put_buffer -> avio_write
put_nbyte will be made private
put_tag will be merged with avio_put_str
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Anton Khirnov
Luca Barbato
Michael Niedermayer
Andrew Stone
Josh Allmann
Martin Storsjö
Clément Bœsch
Rafaël Carré
Björn Axelsson
Diego Biurrun
Benjamin Larsson
Ronald S. Bultje
Damien Fetis
James Zern
Mans Rullgard
Justin Ruggles
Diego Elio Pettenò
Stefano Sabatini