Michael Niedermayer:
> A threshold of 180 is needed and sufficient for the sample, twice this is
> used to
> cover potentially worse samples
>
> fate/vp5 changes as the sample file is truncated and the damaged part is
> handled
> differently
>
> Fixes: ticket #9754
>
> Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
> ---
> libavcodec/vpx_rac.h | 2 +-
> tests/ref/fate/vp5 | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vpx_rac.h b/libavcodec/vpx_rac.h
> index b158cc0754..2f5486f501 100644
> --- a/libavcodec/vpx_rac.h
> +++ b/libavcodec/vpx_rac.h
> @@ -52,7 +52,7 @@ static av_always_inline int vpx_rac_is_end(VPXRangeCoder *c)
> {
> if (c->end <= c->buffer && c->bits >= 0)
> c->end_reached ++;
> - return c->end_reached > 10;
> + return c->end_reached > 360;
Is the file from #9754 defective? Or is it our decoder that is
overcautious? Your commit message sounds as if it were the latter. Is it
guaranteed that is now enough for all spec-compliant samples? Does the
answer depend upon the codec? (vpx_rac_is_end() is shared between
several VPx codecs.); I presume you can't give any guarantees.
> }
>
> static av_always_inline unsigned int vpx_rac_renorm(VPXRangeCoder *c)
> diff --git a/tests/ref/fate/vp5 b/tests/ref/fate/vp5
> index 09ebe62b25..2116fb9b81 100644
> --- a/tests/ref/fate/vp5
> +++ b/tests/ref/fate/vp5
> @@ -249,4 +249,4 @@
> 0, 243, 243, 1, 233472, 0x6f530ac6
> 0, 244, 244, 1, 233472, 0x94f7466c
> 0, 245, 245, 1, 233472, 0xa8c1d365
> -0, 246, 246, 1, 233472, 0x4f3ef38c
> +0, 246, 246, 1, 233472, 0xedcff050
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
