2016-05-04 19:44:35 +00:00
|
|
|
write_data len 36, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 1807, time nopts, type header atom -
|
|
|
|
|
write_data len 496, time 1000000, type sync atom moof
|
|
|
|
|
write_data len 110, time nopts, type trailer atom -
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
07cee26b35b140ae50268c3083e2d880 2449 non-empty-moov
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 36, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 2135, time nopts, type header atom -
|
|
|
|
|
write_data len 616, time 966667, type sync atom moof
|
|
|
|
|
write_data len 110, time nopts, type trailer atom -
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
c3c47c2c9566cb410e0832c37f4f8527 2897 non-empty-moov-elst
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 36, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 2055, time nopts, type header atom -
|
|
|
|
|
write_data len 616, time 1000000, type sync atom moof
|
|
|
|
|
write_data len 110, time nopts, type trailer atom -
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
abc910edf1fc2a205658353dfdfc9a5f 2817 non-empty-moov-no-elst
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 20, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 1195, time nopts, type header atom -
|
|
|
|
|
write_data len 608, time 0, type sync atom moof
|
|
|
|
|
write_data len 652, time nopts, type unknown atom -
|
|
|
|
|
write_data len 608, time 1013106, type sync atom moof
|
|
|
|
|
write_data len 640, time nopts, type unknown atom -
|
|
|
|
|
write_data len 148, time nopts, type trailer atom -
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
e8e0346bf20bfcb448695bd905946f78 3871 ismv
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 36, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 1147, time nopts, type header atom -
|
|
|
|
|
write_data len 500, time 0, type sync atom moof
|
|
|
|
|
write_data len 496, time 1000000, type sync atom moof
|
|
|
|
|
write_data len 148, time nopts, type trailer atom -
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
89ea214e1d1079556164664eea9a7884 2327 empty-moov
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 36, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 1147, time nopts, type header atom -
|
|
|
|
|
write_data len 780, time 0, type sync atom moof
|
|
|
|
|
write_data len 616, time 1000000, type sync atom moof
|
|
|
|
|
write_data len 148, time nopts, type trailer atom -
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
cf9eec38fe557203a37a44c8adafb1fe 2727 empty-moov-no-elst
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 36, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 1147, time nopts, type header atom -
|
|
|
|
|
write_data len 612, time -33333, type sync atom moof
|
|
|
|
|
write_data len 616, time 966667, type sync atom moof
|
|
|
|
|
write_data len 148, time nopts, type trailer atom -
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
42eca5843d98aa9a9b3275de201700b8 2559 empty-moov-no-elst-no-adjust
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 1183, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 500, time 0, type sync atom moof
|
|
|
|
|
write_data len 496, time 1000000, type sync atom moof
|
|
|
|
|
write_data len 148, time nopts, type trailer atom -
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
89ea214e1d1079556164664eea9a7884 2327 delay-moov
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 1255, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 620, time -33333, type sync atom moof
|
|
|
|
|
write_data len 616, time 966667, type sync atom moof
|
|
|
|
|
write_data len 148, time nopts, type trailer atom -
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
8fd78a5a91d73a735da53ac02f844177 2639 delay-moov-elst
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 1183, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 596, time 0, type sync atom moof
|
|
|
|
|
write_data len 67, time nopts, type trailer atom -
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
848d2fe2f27882960b8e10315460bc23 1846 delay-moov-empty-track
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 1183, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 240, time 0, type sync atom moof
|
|
|
|
|
write_data len 240, time 1000000, type sync atom moof
|
|
|
|
|
write_data len 86, time nopts, type trailer atom -
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
cbf60ba66c47b8506c1a724d43f12cdc 1749 delay-moov-empty-track-flush
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 36, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 1147, time nopts, type header atom -
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
c0b13fd47ca4c6de13c03155c38c231c 1183 empty-moov-header
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 500, time 0, type sync atom moof
|
|
|
|
|
write_data len 496, time 1000000, type sync atom moof
|
2015-11-05 22:12:11 +00:00
|
|
|
f12baf7c4269695817337192c7069328 996 empty-moov-content
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 148, time nopts, type trailer atom -
|
|
|
|
|
write_data len 1183, time nopts, type header atom ftyp
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
c0b13fd47ca4c6de13c03155c38c231c 1183 delay-moov-header
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 500, time 0, type sync atom moof
|
|
|
|
|
write_data len 496, time 1000000, type sync atom moof
|
2015-11-05 22:12:11 +00:00
|
|
|
f12baf7c4269695817337192c7069328 996 delay-moov-content
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 148, time nopts, type trailer atom -
|
|
|
|
|
write_data len 24, time nopts, type header atom -
|
|
|
|
|
write_data len 1147, time nopts, type header atom -
|
|
|
|
|
write_data len 588, time 0, type sync atom sidx
|
|
|
|
|
write_data len 584, time 1000000, type sync atom sidx
|
2015-11-05 22:12:11 +00:00
|
|
|
76e1081bbab7541eadcaf4b19d37eff6 584 empty-moov-second-frag
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 148, time nopts, type trailer atom -
|
|
|
|
|
write_data len 24, time nopts, type header atom -
|
|
|
|
|
write_data len 1147, time nopts, type header atom -
|
|
|
|
|
write_data len 584, time 1000000, type sync atom sidx
|
2015-11-05 22:12:11 +00:00
|
|
|
76e1081bbab7541eadcaf4b19d37eff6 584 empty-moov-second-frag-discont
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 110, time nopts, type trailer atom -
|
|
|
|
|
write_data len 1171, time nopts, type header atom -
|
|
|
|
|
write_data len 584, time 1000000, type sync atom sidx
|
2015-11-05 22:12:11 +00:00
|
|
|
76e1081bbab7541eadcaf4b19d37eff6 584 delay-moov-second-frag-discont
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 110, time nopts, type trailer atom -
|
|
|
|
|
write_data len 1207, time nopts, type header atom ftyp
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
fdc08ccfb9ca1a7a63a8e82a99e28e83 1207 delay-moov-elst-init
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 700, time -33333, type sync atom sidx
|
|
|
|
|
write_data len 704, time 966667, type sync atom sidx
|
2015-11-07 21:55:32 +00:00
|
|
|
41afdc44b0e376fae49a730afe0c53c2 704 delay-moov-elst-second-frag
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 148, time nopts, type trailer atom -
|
|
|
|
|
write_data len 1207, time nopts, type header atom ftyp
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
fdc08ccfb9ca1a7a63a8e82a99e28e83 1207 delay-moov-elst-init-discont
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 704, time 966667, type sync atom sidx
|
2015-11-07 21:55:32 +00:00
|
|
|
41afdc44b0e376fae49a730afe0c53c2 704 delay-moov-elst-second-frag-discont
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 110, time nopts, type trailer atom -
|
|
|
|
|
write_data len 1243, time nopts, type header atom ftyp
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
57c113cd2baf7b231355eee6980fb6b5 1243 delay-moov-elst-signal-init
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 708, time -33333, type sync atom sidx
|
|
|
|
|
write_data len 704, time 966667, type sync atom sidx
|
2015-11-10 21:33:44 +00:00
|
|
|
13b8487a4f004ec9f1db543aee1e5e18 704 delay-moov-elst-signal-second-frag
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 148, time nopts, type trailer atom -
|
|
|
|
|
write_data len 1243, time nopts, type header atom ftyp
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
57c113cd2baf7b231355eee6980fb6b5 1243 delay-moov-elst-signal-init-discont
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 704, time 966667, type sync atom sidx
|
2015-11-10 21:33:44 +00:00
|
|
|
13b8487a4f004ec9f1db543aee1e5e18 704 delay-moov-elst-signal-second-frag-discont
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 110, time nopts, type trailer atom -
|
|
|
|
|
write_data len 1243, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 1552, time -333333, type sync atom sidx
|
|
|
|
|
write_data len 704, time 5166667, type sync atom sidx
|
|
|
|
|
write_data len 148, time nopts, type trailer atom -
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
5e676152714f9478b5f74ce67cd7ed60 3647 vfr
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 1243, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 1552, time -333333, type sync atom sidx
|
|
|
|
|
write_data len 704, time 5166667, type sync atom sidx
|
|
|
|
|
write_data len 148, time nopts, type trailer atom -
|
lavf: replace AVStream.codec with AVStream.codecpar
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.
2014-06-18 18:42:52 +00:00
|
|
|
5e676152714f9478b5f74ce67cd7ed60 3647 vfr-noduration
|
2016-05-04 19:44:35 +00:00
|
|
|
write_data len 1255, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 1500, time -333333, type sync atom moof
|
|
|
|
|
write_data len 620, time nopts, type unknown atom -
|
|
|
|
|
write_data len 1500, time 9666667, type sync atom moof
|
|
|
|
|
write_data len 664, time nopts, type unknown atom -
|
|
|
|
|
write_data len 148, time nopts, type trailer atom -
|
|
|
|
|
03766894d839e5fcb1edb88498d812f7 5687 large_frag
|
2016-05-09 10:48:58 +00:00
|
|
|
write_data len 1255, time nopts, type header atom ftyp
|
|
|
|
|
write_data len 508, time -33333, type sync atom moof
|
|
|
|
|
write_data len 372, time 800000, type boundary atom moof
|
|
|
|
|
write_data len 328, time 1266667, type boundary atom moof
|
|
|
|
|
write_data len 476, time 1566667, type sync atom moof
|
|
|
|
|
write_data len 340, time 2233333, type boundary atom moof
|
|
|
|
|
write_data len 262, time nopts, type trailer atom -
|
|
|
|
|
a4280bdc23af2c4334ec2da3fa946d3a 3541 vfr-noduration-interleave
|
