On Wed, 11 Jul 2012, Derek Buitenhuis wrote:
On 11/07/2012 2:17 PM, Martin Storsjö wrote:
+ if (s->signaling < 0)
+ s->signaling = avctx->flags & CODEC_FLAG_GLOBAL_HEADER ? 2 : 0;
We use this exact thing directly above. Should be set, then used there
instead of duplicating code.
No, it's not exactly the same, it's the inverse, and the fact that both
use numbers 0 and 2 is a coincidence.
Above is
if (extradata requested) { mp4 format } else { adts format }.
This one is:
if (no signalling mode requested by the caller)
if (extradata requested) { explicit hierarchical signalling } else
{ implicit signalling }
Where mp4 format is 0, adts format is 2, implicit signalling is 0 and
hierarchical signalling is 2.
Seems I missed the inverse bit. My question is why do the both use
CODEC_FLAG_GLOBAL_HEADER? Seems pretty hacky and confusing to me.
It's the norm for how AAC encoders in libavcodec work at the moment,
afaik. You have these two different bitstream formats, extradata + raw
access units (mp4 style) or no extradata and the corresponding data
prepended in the header (ADTS) - kinda like annexb vs mp4 for H264. That's
all about the first section above.
Then for the signaling mode, Alex explained it to me that we should prefer
using explicit signaling if possible, since that's, well, explicit with
what features the bitstream uses. This mode isn't possible when using ADTS
though, so then we have to use implicit signaling (as default).
Comment on where FFMAX(8192, 768 * avctx->channels) comes from, please.
I copied this from vo-aacenc, where Justin added it at some point. I think
the encoder lib has a comment about the bounds of the encoded data, I'll
try to look it up.
Thanks.
Is this really proper?
I don't see what wouldn't be proper here. We consumed the input data, but
the encoder didn't output anything yet, so we signal that everything is ok
but no data was returned.
I'm more wondering if this is a valid thing for libfdk-aac to do? I'm
clearly no AAC expert.
Hmm, it actually didn't happen at the start as I thought, but it does
happen at the end when flushing the encoder.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
