On 02/04/2014 04:38 AM, Tim Walker wrote:
> On 03 Feb 2014, at 00:24, John Stebbins <[email protected]> wrote:
>
>> This does make a functional difference.  I looked for the fallback code you 
>> mention.  It looks like it is in
>> ff_get_buffer()?  In aacdec, ff_get_buffer is called before 
>> avctx->sample_rate has been set for the first time.  So the
>> first frame returned does not has an AVFrame.sample_rate == 0.
> Is the sample_rate information available before calling get_buffer? If so, it 
> may be useful to set the context sample_rate earlier (in addition to this 
> patch)?
>
>

It looks like the code is currently structured to go ahead and do some 
decoding, even if the adts header (and thus the
sample rate) has not been seen yet.  I'm  not sure what use a frame with no 
sample rate would be, but it appears the
code can return a frame even before avctx->sample_rate is set.  It could easily 
be modified to prevent processing of
data till the header is parsed, but I'm not familiar enough with aac codec to 
know if this would cause incorrect
decoding in any cases.

It appears that the regular aac parser (ff_aac_ac3_parse) waits for sync first 
(i.e. waits for adts header).  So
av_parser_parse2() would normally find the sample_rate before decode starts. 
But the latm parser does not appear to wait
for sync.

-- 
John      GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01  83F0 49F1 D7B2 60D4 D0F7


Attachment: signature.asc
Description: OpenPGP digital signature

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

Reply via email to