On 12/13/2011 09:06 AM, Martin Storsjö wrote: > On Tue, 13 Dec 2011, Justin Ruggles wrote: > >> I can't think of anything better right now, but it does seem a little >> odd to me. Before decoding, the sample_rate is set by the user (via the >> flv demuxer). The nellymoser decoder doesn't currently touch >> sample_rate. If the point of the flag is to have the change come from >> the decoder, what advantage does that have over the demuxer changing the >> sample_rate directly? I know that the user changing certain fields after >> init() will lead to bad things sometimes, but we don't have any >> documented rules about such things do we? > > The advantage is that sample_rate is updated only once you actually decode > that packet - you might demux and fill a buffer of packets, but the sample > rate change isn't made effective until you actually decode them, otherwise > you'd get wrong sample rate for a few of the preceding packets.
indeed. sounds like an alright solution then. making the side data type "new extradata" seems ok too. -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
