<div dir="ltr"><div><div><div><div><div><div><div><div>Perette,<br></div>as far as I can tell there are 2 different things relating to codecs:<br><br></div>old API:<br>AVCodecContext - obtained from stream->codec (this may be the source of confusion), a pointer which is passed into functions dealing with the codec<br></div>AVCodec - obtained from av_codec_find_decoder(context), contains fields like width, height, stream type etc.<br><br><br></div>new API:<br></div>AVCodecParams - obtained from stream->codec_params, equivalent to AVCodec in old API<br></div>AVCodecContext - allocated, then set from codec_params<br><br><br></div><br></div>I could be wrong, I have not experimented with the new API yet. Just looking at code.<br><br><br><br><br><br><div><br><br><div><div><div><div><br><div><br></div></div></div></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br><a href="http://lives-video.com" target="_blank">http://lives-video.com</a><br><a href="https://www.openhub.net/accounts/salsaman" target="_blank">https://www.openhub.net/accounts/salsaman</a><br></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Aug 22, 2016 at 10:04 AM, Perette Barella <span dir="ltr"><<a href="mailto:perette@barella.org" target="_blank">perette@barella.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Salsaman,<br>
<br>
I reviewed the doc/examples and my existing, working code some more, and I’m going to step back and ask some architectural questions to validate changing assumptions based on your assertions.<br>
<br>
* AVFormat provides the I/O and multiplexing for media<br>
* AVStream is an abstraction for the separate audio/video/subtitle components of the media. It is associated with an AVFormatContext.<br>
* AVCodec provides the encoder/decoders for a particular AV type.<br>
<br>
My assumption has been that since AVStream->codec exists and was filled in by avformat_new_stream and other functions, and *that there was an association between an AVStream and its AVCodec* so that all these different components worked together.<br>
<br>
You’re implying that no such association exists, and that it’s entirely my code that’s pushing packets through the Codec, then moving the results onto the Stream. I find this a little surprising, although I find nothing in my code or the examples/muxing.c to contradict it. And it would explain why it takes to much code to do anything with lav as opposed to gstreamer or other libraries.<br>
<br>
Am I going in the right direction now?<br>
<br>
And with that in mind, then the purpose of codecpar is a way for the stream to *provide* parameters for a codec that I’m supposed to create, and the codec structure was there in the past only to provide and not an indication of association between the codec and the stream (because no such association exists).<br>
<span class=""><br>
> Just use avctx from the code above. I don' t see what the problem is.<br>
<br>
<br>
</span>I think one of lav’s problems is lack of a good architectural diagram to explain how it’s *supposed* to work. Yes, i can read the code and the examples, and the Doxygen is a big help… but some sense of the intent and design behind the code would help significantly. It’s like the difference between diagnosing an electrical problem with vs. without a blueprint/schematic: you can do without, but having the picture makes the work easier, faster and more accurate.<br>
<span class="HOEnZb"><font color="#888888"><br>
Perette<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" rel="noreferrer" target="_blank">http://ffmpeg.org/mailman/<wbr>listinfo/libav-user</a><br>
</div></div></blockquote></div><br></div>