Hi,
I hereby present my entry to this year's ridiculously oversized patchset
competition.

The theme this time is further decoupling of lavf and lavc. Currently, AVStream
has an embedded AVCodecContext, which is used to transfer stream properties from
demuxers to callers or from callers to muxers. It is also used by
avformat_find_stream_info() as the decoding context and by parsers. When the
caller is using lavc for encoding or decoding, it is also commonly used as the
encoding/decoding codec context.

There are multiple problems with this, mainly:
- The demuxer, the parser and the decoder all fight over overwriting the codec
  context. Due to frame threading there can be considerable delay between the
  three, resulting in bogus values being read or written.
- The mixing of stream parameters and codec options / state in AVCodecContext
  makes it hard to use lavf and lavc independently in the caller programs.
  avcodec_copy_context() is by neccesity quite fragile and until recently was
  broken in many cases.
- Related to the above, many muxers and demuxers rely on the stream codec
  context being the actual encoding/decoding context, resulting in obscure bugs.

The solution presented here is adding a new structure, AVCodecParameters, which
holds only stream parameters, without any codec state. It replaces the codec
context embedded in AVStream (which becomes deprecated). Functions are provided
to fill AVCodecContext from AVCodecParameters or vice versa. I expect this
struct to also be used in bitstream filters and parsers in the future.

The branch currently has 198 patches, with each demuxer/muxer/other separate
unit being treated in a separate patch. This is done to simplify review, most of
the patches will have to be squashed in the end. Most of the patches are very
boring s/->codec/->codecpar/ replacements, but some are more tricky (mainly due
to abusing codec options, as mentioned above). About 15 demuxers are still to be
finished, but I'm sending this RFC with the core changes and some example
conversions now to get some comments on the big picture.

-- 
Anton Khirnov
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to