2017-03-07 12:30 GMT+01:00 Michał Krasowski :
>>> There are few things that are still not clear to me:
>>> * Why is the 32 bit padding used when the doc says that
>>> 64 bit offset may also be needed?
>>
>>I don't understand your question but you may want to
>>send an update for this sentence.
>
On Tue, Mar 07, 2017 at 11:55:23AM +0100, Michał Krasowski wrote:
> @Michael Niedermayer
> I have read the documentation, namely
>
> /**
> * @ingroup lavc_decoding
> * Required number of additionally allocated bytes at the end of the input
> bitstream for decoding.
> * This is mainly needed bec
>> This email may contain Opera confidential information
>
>Please remove this, Carl Eugen
Ah, yes, default footer, sorry.
>> There are few things that are still not clear to me:
>> * Why is the 32 bit padding used when the doc says that
>> 64 bit offset may also be needed?
>
>I don't understand
2017-03-07 11:55 GMT+01:00 Michał Krasowski :
> @Michael Niedermayer
> I have read the documentation, namely
>
> /**
> * @ingroup lavc_decoding
> * Required number of additionally allocated bytes at the end of the input
> bitstream for decoding.
> * This is mainly needed because some optimized b
On Tue, 7 Mar 2017 11:55:23 +0100
Michał Krasowski wrote:
> @Michael Niedermayer
> I have read the documentation, namely
>
> /**
> * @ingroup lavc_decoding
> * Required number of additionally allocated bytes at the end of the input
> bitstream for decoding.
> * This is mainly needed because s
On Tue, Mar 7, 2017 at 11:55 AM, Michał Krasowski wrote:
> @Michael Niedermayer
> I have read the documentation, namely
>
> /**
> * @ingroup lavc_decoding
> * Required number of additionally allocated bytes at the end of the input
> bitstream for decoding.
> * This is mainly needed because some
@Michael Niedermayer
I have read the documentation, namely
/**
* @ingroup lavc_decoding
* Required number of additionally allocated bytes at the end of the input
bitstream for decoding.
* This is mainly needed because some optimized bitstream readers read
* 32 or 64 bit at once and could read
On Mon, Mar 06, 2017 at 03:51:51PM +0100, Michał Krasowski wrote:
> It seems that the loop tried to access the memory regions
> beyond allocation, what caused crashes in not-so-rare cases, when
> the memory read did not belong to current process.
>
> This change is fixing the out-of-bounds read pr
It seems that the loop tried to access the memory regions
beyond allocation, what caused crashes in not-so-rare cases, when
the memory read did not belong to current process.
This change is fixing the out-of-bounds read problem.
Compiling this function with -fsanitize=address and running doesn't
r
