Missing docs found by: nevcairiel
RFC: should we add support so that the C field names always work as av option names/keys ?
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We cannot deprecate it until the new parser API is in place, because of
the way libavformat works. But the majority of the users can already
simply replace it with avcodec_free_context(), which will simplify the
transition once it is finally deprecated.
This function is supposed to "reset" a codec context to a clean state so
that it can be opened again. The only reason it exists is to allow using
AVStream.codec as a decoding context (after it was already
opened/used/closed by avformat_find_stream_info()). Since that behaviour
is now deprecated, there is no reason for this function to exist
anymore.
Since AVCodecContext contains a lot of complex state, copying a codec
context is not a well-defined operation. The purpose for which it is
typically used (which is well-defined) is copying the stream parameters
from one codec context to another. That is now possible with through the
AVCodecParameters API. Therefore, there is no reason for
avcodec_copy_context() to exist.
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>
The bits_per_raw_sample represents the number of bits of precision per sample.
The field is added at the logical place, not at the end as the code was just
recently added
This fixes the regression about losing the audio sample precision information
The change in the fate test checksum un-does the change from the merge
Previous version reviewed by: wm4 <nfxjfg@googlemail.com>
Previous version reviewed by: Dominik 'Rathann' Mierzejewski <dominik@greysector.net>
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.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Luca Barbato
Michael Niedermayer
James Almer
Carlos Fernandez
Vittorio Giovara
Timo Rothenpieler
Sasi Inguva
Yogender Gupta
Carl Eugen Hoyos
Stanislav Dolganov
Paul B Mahol
Jon Toohill
Jan Sebechlebsky
Timothy Gu
Mark Reid
Anton Khirnov
Francois Cartegnie
Peter Ross
wm4
Martin Storsjö
Derek Buitenhuis
Hendrik Leppkes
Lou Logan