On Fri, Oct 21, 2011 at 05:58:45PM -0400, Justin Ruggles wrote:
> using a floating-point calculation is not necessary.
> ---
> libavcodec/tta.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/tta.c b/libavcodec/tta.c
> index 31f861c..419091b 100644
> --- a/libavcodec/tta.c
> +++ b/libavcodec/tta.c
> @@ -217,7 +217,7 @@ static av_cold int tta_decode_init(AVCodecContext * avctx)
> avctx->bits_per_coded_sample = get_bits(&s->gb, 16);
> s->bps = (avctx->bits_per_coded_sample + 7) / 8;
> avctx->sample_rate = get_bits_long(&s->gb, 32);
> - if(avctx->sample_rate > 1000000){ //prevent FRAME_TIME *
> avctx->sample_rate from overflowing and sanity check
> + if (avctx->sample_rate > 8388607) { // prevent overflow in
> frame_length calculation
in hex please, 0x7FFFFF looks much nicer
> av_log(avctx, AV_LOG_ERROR, "sample_rate too large\n");
> return -1;
> }
> @@ -236,9 +236,7 @@ static av_cold int tta_decode_init(AVCodecContext * avctx)
> return AVERROR(EINVAL);
> }
>
> - // FIXME: horribly broken, but directly from reference source
> -#define FRAME_TIME 1.04489795918367346939
> - s->frame_length = (int)(FRAME_TIME * avctx->sample_rate);
> + s->frame_length = 256 * avctx->sample_rate / 245;
the ratio is right and I hope it was tested to output the same results on all
range of samplerates.
In general patch looks OK
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
