Justin Ruggles <[email protected]> writes: > On 10/24/2011 10:04 AM, Måns Rullgård wrote: > >> Justin Ruggles <[email protected]> writes: >> >>> --- >>> libavcodec/tta.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/libavcodec/tta.c b/libavcodec/tta.c >>> index 5a11436..9330e2d 100644 >>> --- a/libavcodec/tta.c >>> +++ b/libavcodec/tta.c >>> @@ -182,7 +182,7 @@ static int tta_get_unary(GetBitContext *gb) >>> int ret = 0; >>> >>> // count ones >>> - while(get_bits1(gb)) >>> + while (get_bits_left(gb) > 0 && get_bits1(gb)) >>> ret++; >>> return ret; >>> } >>> -- >> >> Patch OK. >> >> What is the maximum legal length here? If the value is likely to fit in >> the bitstream cache, this can be optimised considerably. > > The rice param, k, can be 0. So the limit on unary length is the range > of the prediction error, which is about the same as the input sample range.
If that happens frequently, unary coding is probably not the best choice. In fact, exp-golomb is more efficient if the average value is greater than 4, and that gives way to other codings for moderately large values. Thus, either the tta designers were stupid (certainly a possibility) or these values are small most of the time. If anyone cares about performance, this might be a place to look. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
