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?
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
