On 12/13/2011 05:14 AM, Martin Storsjö wrote: > On Sat, 3 Dec 2011, Martin Storsjö wrote: > >> On Fri, 2 Dec 2011, Luca Barbato wrote: >> >>> On 12/2/11 2:26 PM, Martin Storsjö wrote: >>>> On Fri, 2 Dec 2011, Luca Barbato wrote: >>>> >>>>> On 12/2/11 10:57 AM, Martin Storsjö wrote: >>>>> >>>>> Possibly we could export this information as a defined and generic >>>>> struct, I guess there is more than this container-codec interaction >>>>> that could signal configuration parameters change. >>>> >>>> Possibly, but I'm not sure if this particular approach is generic enough >>>> for all of them. E.g., for AAC in FLV, extradata is in a separate >>>> packet. If a new packet of that kind appears, I'm not sure if the >>>> demuxer should try to decode it and parse it to some info struct - >>>> instead I'd just pass that extradata on e.g. as side data to the next >>>> packet, so the decoder can notice it. In that sense, this flv flags >>>> field could be viewed as one kind of extradata for nellymoser/flv. >>> >>> Ideally we should be able to remux nellymoser in something different than >>> flv and preserve the information. I know that's close to nitpicking but >>> having too many different kinds of side data might be annoying. > > Are there any other containers that support nellymoser and support this > metadata per frame (that is, supported elsewhere than just what we come up > with ourselves)? If not, this isn't really doable, even if we consider > these flv packet flags as extradata for nellymoser. > > But generally, a way to pass updated extradata for e.g. AAC might be good, > too, because that can sure happen in FLV, but then it'd be a different > kind of side data packet, a plain "new extradata" side data packet. > >> So, should we apply this patchset, or do we wait for a better solution? > > Any suggestions on how to move forward with this, Justin, others?
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? -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
