On 02/05/2014 09:40 AM, John Stebbins wrote: > 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. >
On further examination, I see that the latm code path also parses sample_rate before starting decoding. So the above comment about latm is incorrect. But we still can't move initialization of sample_rate earlier because the sample_rate value can depend on the sbr extension which isn't parsed till later. -- John GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01 83F0 49F1 D7B2 60D4 D0F7
signature.asc
Description: OpenPGP digital signature
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
