On 20 March 2017 at 19:52, Alex Converse <[email protected]> wrote:
> Aliased compressed AAC bytes are almost certainly not meaningful SBR
> data. In the wild this causes harsh artifacts switching HE-AAC streams
> that don't have SBR headers aligned with segment boundaries.
>
> Turning off SBR falls back to a default set of upsampling parameters
> that can function as a sort of error concealment. This is consistent
> with how the decoder handles other sorts of errors.
> ---
> libavcodec/aacsbr_template.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
> index cf8621eee0..750131c64c 100644
> --- a/libavcodec/aacsbr_template.c
> +++ b/libavcodec/aacsbr_template.c
> @@ -1137,6 +1137,7 @@ int AAC_RENAME(ff_decode_sbr_extension)(AACContext
> *ac, SpectralBandReplication
> if (bytes_read > cnt) {
> av_log(ac->avctx, AV_LOG_ERROR,
> "Expected to read %d SBR bytes actually read %d.\n", cnt,
> bytes_read);
> + sbr_turnoff(sbr);
> }
> return cnt;
> }
>
LGTM, makes sense if the SBR data is corrupt given how SBR works
_______________________________________________
ffmpeg-devel mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
