On Tue, 13 Dec 2011, Justin Ruggles wrote:
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.
Hmm, ok then. I'll try to implement them both and see what it looks like.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
