On 11/07/2012 3:30 PM, Martin Storsjö wrote:
>> 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).

I saw you added a comment, so it gets an OK from me.

>>>> 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.

I'll leave this for you to decide on / look into then.

- Derek
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to