AVStream.codecpar

[mikeboers]

Lots of people are opening issues and/or sending emails that contain:

Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.

Perhaps we should do that.

The warning comes from mux.c:300, called from avformat_init_output, called from avformat_write_header. It is looking at AVCodecContext.codec_type, seeing that it is set, and then issuing the warning.

My guess is that it is being set by avcodec_open2, as we are manually opening all of the streams before writing the container header. (Oops?) I'm not sure if that actually makes sense.

[mikeboers]

Looking at the example the problem isn't that we set the parameters on AVCodecContext, but just that they weren't also set on the AVStream.codecpar.

This kinda makes sense, as it means that libavformat becomes more isolated from libavcodec. You may not need codec contexts at all for [de]muxing.

So, maybe, all we need to do is call avcodec_parameters_from_context

[mikeboers]

(Take with a grain of salt:)

Maybe we ought to consider that streams don't need a codec context... because they strictly don't. The content could be encoded elsewhere.

We then expose each of the properties on AVCodecParameters on the stream object, and have it set to a param struct, AND the codec context (if it exists). Or it sets it to one before the context is opened and the other after. We would then also be not nessesarily opening the codec context for writing until we need to (or are asked to).

This sort of very repetitive thing makes me want to dig out the Cython templating branch that I've been slowly rebasing up the chain every few months.

[jlaine]

My current understanding is that AVCodecParameters will give you the parameters it discovered on an input stream. If we need an AVCodecContext for use with a stream, we should be allocating it, storing the pointer somewhere, and de-allocating it - and not using AVStream.codec at all.

On the whole this doesn't seem to be a major issue, however there is at least one place where it is : ContainerContext.flush_buffers. This assumes we can just look into the AVStream.codec to get a handle to the CodecContext, which won't be true anymore : we will need access to the (Python) Stream. I'd be grateful for some more explanations about how this "proxy" class breaks reference loops.. as it looks like we do need both the Container to access its Streams and the reverse.

Edit: my question about ContainerProxy seems to relate to #271