On 12/13/2011 10:25 AM, Martin Storsjö wrote: > On Tue, 13 Dec 2011, Luca Barbato wrote: > >> On 13/12/11 16:08, Martin Storsjö wrote: >>> As I said, if I later get to implementing the same for AAC in FLV, I'll >>> do that as "new extradata", since the info for AAC actually is passed as >>> extradata, and there it is much more clear that new extradata is passed >>> along only occasionally when it has changed, not for every packet like >>> it is here. >> >> I'm against proliferation of random and overly specific side data. If >> there are impelling reasons to introduce it _NOW_ so be it. > > This is a missing feature I need at $dayjob, that's one reason. > > The alternative would be, as far as I see it, to invent some form of > extradata for nellymoser, check the flags field in the flv demuxer and > then emit that as "new extradata" side data if it changes. > > Since there is no specification of what that extradata would be, it could > e.g. simply be the flv flags field for nellymoser. > > The alternative that you suggested at some point, a struct for "audio > format change", that could be passed along as side data (which of course > would have to be byte packed with bytestream reading/writing functions > instead of just memcpying a struct blindly) - that would of course also be > an option, where we wouldn't need to invent a new form of extradata for > nellymoser, and would be easier to interpret e.g. when stream copying. But > for e.g. AAC, where this info isn't conveyed by the FLV flags but in the > AAC extradata packets in the stream, the "new extradata" approach feels > better than "audio format change" side data packets, since we don't have > to parse the AAC extradata in the FLV demuxer if we just pass it along. > > So, what do people think is the best approach?
both? I like the option of having a generic side data type for basic parameter changes that isn't container-specific or codec-specific. But I also like the idea of a new extradata side data type for more complex mid-stream changes that require codec-specific parsing like for AAC. -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
