<div dir="ltr"><div><div><div><div><div><div><div><div>Hello,<br><br></div>I've seasoned programmer but just started programming with LibAV.  I've gone through some tutorials (dranger), and read the example code but I have a couple of questions about things I'm not certain on.  Since there doesn't seem to be official documentation on what I'm asking, I thought I'd ask here for clarification and hopefully shed some light for any future seekers:<br><br></div><div><u>AVOptions vs. AVDictionary<br></u><br></div>There appear to be two methods of settings options on objects.  One is using the AVOptions API and one is passing in an AVDictionary during creation of an object.  The AVOptions API is preferable to myself in that I get immediate feedback if something doesn't work (I spent an hour trying to set a constant, when in reality I should have been setting fflags to that constant).  However, I'm curious as to why both options exist.  Is one about to be deprecated?  Is there one I should prefer over the other?<br><br></div><u>AVCodecContext vs. AVCodecParameters<br></u><br></div>It appears that a couple of years ago AVCodecParameters was introduced to group common (most often shared) codec parameters into a single class and un-bloat AVCodecContext, is this correct?<br><br></div>It also appears that a lot of accesses to AVCodecContext directly are deprecated (e.g. AVStream::codec).  If I'm not supposed to use AVCodecContext, it follows that I should not be using AVOptions API on that object, and should instead be using AVDictionary in this case; is that correct?<br><br></div>It also seems I stumbled upon a debate about AVOptions on AVCodecParameters, with the outcome being that you cannot use AVOptions on AVCodecParameters.  It appears a consequence of this is that some functionality I was going to rely upon (such as setting video_size=wxh and pixel_format) will not work correctly as this should be done on AVCodecParameters (where width, height, and format live) as opposed to AVCodecContext (whose use is being deprecated).  With that said, is the design that I should be never allow the user to specify such things, as I need to set them on AVCodecParameters, is it that I need to re-create a parser for such options and set them on AVCodecParameters, or have I missed somewhere that applies these to AVCodecParameters?<br><br></div><div><u>Muxing Example<br><br></u></div><div>In the muxing example (<a href="https://git.ffmpeg.org/gitweb/ffmpeg.git/blob_plain/HEAD:/doc/examples/muxing.c">https://git.ffmpeg.org/gitweb/ffmpeg.git/blob_plain/HEAD:/doc/examples/muxing.c</a>), it appears to ignore the avformat_new_stream documentation and avoid opening the codec (which would put it into AVStream::codec) and instead create its own copy to avoid deprecation warnings:<br><br> * @param c If non-NULL, the AVCodecContext corresponding to the new stream<br> * will be initialized to use this codec. This is needed for e.g. codec-specific<br> * defaults to be set, so codec should be provided if it is known.<br><br>It also seems to avoid AVCodecParameters altogether on the encoding side (except for a final step to copy from the configured context).  Is this the new preferred method on the encoding side?<br></div><div><u></u></div><div><br></div>Thank you in advance for your time.<br><br></div>Sincerely,<br>Jodon Karlik<br></div>