On 5/20/2016 10:13 AM, Christophe Gisquet wrote:
> Hi,
>
> 2016-05-20 15:09 GMT+02:00 foo86 :
>
>>> Not that the patch is not ok, but I have a few uneducated questions:
>>> 1) Given the get_bits_long(gb, k) afterwards, won't that code cause
>>> overreads for corrupted bitstreams?
>>
>> This will
On Fri, May 20, 2016 at 03:13:22PM +0200, Christophe Gisquet wrote:
> > This is for valid bitstreams. There is no indication of limit on maximum
> > Rice code length in the XLL spec, hence existing constant is not
> > strictly "valid" (but it always worked in practice with existing
> > encoders). R
Hi,
2016-05-20 15:09 GMT+02:00 foo86 :
>> Not that the patch is not ok, but I have a few uneducated questions:
>> 1) Given the get_bits_long(gb, k) afterwards, won't that code cause
>> overreads for corrupted bitstreams?
>
> This will cause overread, but that should not be a problem for checked
>
On Fri, May 20, 2016 at 02:35:53PM +0200, Christophe Gisquet wrote:
> 2016-05-13 11:48 GMT+02:00 foo86 :
> > -unsigned int v = get_unary(gb, 1, 128);
> > +unsigned int v = get_unary(gb, 1, get_bits_left(gb));
>
> Not that the patch is not ok, but I have a few uneducated questions:
> 1) Giv
On 5/20/16, Christophe Gisquet wrote:
> 2016-05-13 11:48 GMT+02:00 foo86 :
>> -unsigned int v = get_unary(gb, 1, 128);
>> +unsigned int v = get_unary(gb, 1, get_bits_left(gb));
>
> Not that the patch is not ok, but I have a few uneducated questions:
> 1) Given the get_bits_long(gb, k) afte
2016-05-13 11:48 GMT+02:00 foo86 :
> -unsigned int v = get_unary(gb, 1, 128);
> +unsigned int v = get_unary(gb, 1, get_bits_left(gb));
Not that the patch is not ok, but I have a few uneducated questions:
1) Given the get_bits_long(gb, k) afterwards, won't that code cause
overreads for corr
On 5/20/16, foo86 wrote:
> Ping.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http:
Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Limit the maximum length of unary part of Rice code by the number of
available bits instead of using an arbitrary constant that happens to be
just large enough to work.
---
libavcodec/dca_xll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dca_xll.c b/libavcodec/dc
