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