Chiebot-Mirror
/
FFmpeg
mirror of https://github.com/FFmpeg/FFmpeg.git
8
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
43203 Commits
37 Branches
400 Tags
465 MiB
Tag: Branch: Tree: 71852a1ba8
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '71852a1ba8'
${ noResults }
FFmpeg/tests/ref/fate/movenc

29 lines
1.7 KiB
Raw Normal View History Unescape

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.
11 years ago
07cee26b35b140ae50268c3083e2d880 2449 non-empty-moov
c3c47c2c9566cb410e0832c37f4f8527 2897 non-empty-moov-elst
abc910edf1fc2a205658353dfdfc9a5f 2817 non-empty-moov-no-elst
e8e0346bf20bfcb448695bd905946f78 3871 ismv
89ea214e1d1079556164664eea9a7884 2327 empty-moov
cf9eec38fe557203a37a44c8adafb1fe 2727 empty-moov-no-elst
42eca5843d98aa9a9b3275de201700b8 2559 empty-moov-no-elst-no-adjust
89ea214e1d1079556164664eea9a7884 2327 delay-moov
8fd78a5a91d73a735da53ac02f844177 2639 delay-moov-elst
848d2fe2f27882960b8e10315460bc23 1846 delay-moov-empty-track
cbf60ba66c47b8506c1a724d43f12cdc 1749 delay-moov-empty-track-flush
c0b13fd47ca4c6de13c03155c38c231c 1183 empty-moov-header
movenc: Add an API unit test for fragmenting options/calls Contrary to the normal fate tests that run via avconv, this tests nontrivial call sequences that are only doable via the API (mainly for different corner cases when using the muxer for segmenting). The test muxes fake packet data (with extradata that looks enough like proper data to make the file be viewable with e.g. boxdumper) and checks the hash of the produced files. The test also verifies that fragments produced via different call sequences remain identical (to avoid e.g. updating the output hashes and suddenly having fragments that used to be identical suddenly diverging), for fragments written with frag_discont and/or delay_moov. Signed-off-by: Martin Storsjö <martin@martin.st>
9 years ago
f12baf7c4269695817337192c7069328 996 empty-moov-content
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.
11 years ago
c0b13fd47ca4c6de13c03155c38c231c 1183 delay-moov-header
movenc: Add an API unit test for fragmenting options/calls Contrary to the normal fate tests that run via avconv, this tests nontrivial call sequences that are only doable via the API (mainly for different corner cases when using the muxer for segmenting). The test muxes fake packet data (with extradata that looks enough like proper data to make the file be viewable with e.g. boxdumper) and checks the hash of the produced files. The test also verifies that fragments produced via different call sequences remain identical (to avoid e.g. updating the output hashes and suddenly having fragments that used to be identical suddenly diverging), for fragments written with frag_discont and/or delay_moov. Signed-off-by: Martin Storsjö <martin@martin.st>
9 years ago
f12baf7c4269695817337192c7069328 996 delay-moov-content
76e1081bbab7541eadcaf4b19d37eff6 584 empty-moov-second-frag
76e1081bbab7541eadcaf4b19d37eff6 584 empty-moov-second-frag-discont
76e1081bbab7541eadcaf4b19d37eff6 584 delay-moov-second-frag-discont
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.
11 years ago
fdc08ccfb9ca1a7a63a8e82a99e28e83 1207 delay-moov-elst-init
movenc: Add a unit test for frag_discont with edit lists This tests the case where the muxer correctly guesses that a stream starts at pts=0. Signed-off-by: Martin Storsjö <martin@martin.st>
9 years ago
41afdc44b0e376fae49a730afe0c53c2 704 delay-moov-elst-second-frag
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.
11 years ago
fdc08ccfb9ca1a7a63a8e82a99e28e83 1207 delay-moov-elst-init-discont
movenc: Add a unit test for frag_discont with edit lists This tests the case where the muxer correctly guesses that a stream starts at pts=0. Signed-off-by: Martin Storsjö <martin@martin.st>
9 years ago
41afdc44b0e376fae49a730afe0c53c2 704 delay-moov-elst-second-frag-discont
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.
11 years ago
57c113cd2baf7b231355eee6980fb6b5 1243 delay-moov-elst-signal-init
movenc: Add a unit test for signaling of the track start times Signed-off-by: Martin Storsjö <martin@martin.st>
9 years ago
13b8487a4f004ec9f1db543aee1e5e18 704 delay-moov-elst-signal-second-frag
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.
11 years ago
57c113cd2baf7b231355eee6980fb6b5 1243 delay-moov-elst-signal-init-discont
movenc: Add a unit test for signaling of the track start times Signed-off-by: Martin Storsjö <martin@martin.st>
9 years ago
13b8487a4f004ec9f1db543aee1e5e18 704 delay-moov-elst-signal-second-frag-discont
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.
11 years ago
5e676152714f9478b5f74ce67cd7ed60 3647 vfr
5e676152714f9478b5f74ce67cd7ed60 3647 vfr-noduration