- 23 Feb, 2016 1 commit
-
-
Anton Khirnov authored
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.
-
- 12 Jan, 2016 1 commit
-
-
Anton Khirnov authored
This test does no encoding, setting the flag was done just to silence the warning removed in the previous commit.
-
- 22 Dec, 2015 1 commit
-
-
Michael Niedermayer authored
Makes greping for non static consts easier Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 07 Dec, 2015 1 commit
-
-
Ganesh Ajjanagadde authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 06 Dec, 2015 1 commit
-
-
Ganesh Ajjanagadde authored
It is required to call va_end for each invocation of va_start within the same function. Fixes: CID 1341583. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
-
- 24 Nov, 2015 1 commit
-
-
Michael Niedermayer authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 23 Nov, 2015 1 commit
-
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 18 Nov, 2015 1 commit
-
-
Derek Buitenhuis authored
This way, it never starts with 0xFFF0, and never trips the ADTS "Detection" code in movenc.c. Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
-
- 16 Nov, 2015 1 commit
-
-
James Almer authored
Signed-off-by: James Almer <jamrial@gmail.com>
-
- 11 Nov, 2015 2 commits
-
-
Martin Storsjö authored
Signed-off-by: Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This tests the case where the muxer correctly guesses that a stream starts at pts=0. Signed-off-by: Martin Storsjö <martin@martin.st>
-
- 10 Nov, 2015 1 commit
-
-
Martin Storsjö authored
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>
-