[FFmpeg-devel] [PATCH] avcodec/dxtory: unbreak decoding after 6e1a167c556

Paul B Mahol onemda at gmail.com
Fri Sep 4 01:27:11 EEST 2020


On 9/3/20, Michael Niedermayer <michael at niedermayer.cc> wrote:
> On Thu, Sep 03, 2020 at 07:03:23PM +0200, Paul B Mahol wrote:
>> get_unary() takes at minimum only 1 bit.
>>
>> Signed-off-by: Paul B Mahol <onemda at gmail.com>
>> ---
>>
>> As this is important fix, will apply in next 5 minutes.
>> I kindly ask authors of various timeouts changes to kindly
>> test their changes more carefully.
>
> Can you provide test samples and a fate test ?

Why should I? Nobody uploads my request to wav CUE thing.

Test samples can be generated by installing trial dxtory capture and recording
mainly black frames from some simple game. On windows, or under virtualbox.

I can upload files, but I value my time and will not do it for nothing
in return.

The ones who are actually paid to the actual work should make sure
they do not break
decoders.

>
>
>>
>> ---
>>  libavcodec/dxtory.c | 10 +++++-----
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavcodec/dxtory.c b/libavcodec/dxtory.c
>> index bc19f27951..3cd95afe80 100644
>> --- a/libavcodec/dxtory.c
>> +++ b/libavcodec/dxtory.c
>> @@ -395,7 +395,7 @@ static int dx2_decode_slice_5x5(GetBitContext *gb,
>> AVFrame *frame,
>>      int stride   = frame->linesize[0];
>>      uint8_t *dst = frame->data[0] + stride * line;
>>
>> -    for (y = 0; y < left && get_bits_left(gb) > 6 * width; y++) {
>> +    for (y = 0; y < left && get_bits_left(gb) >= 3 * width; y++) {
>>          for (x = 0; x < width; x++) {
>>              b = decode_sym_565(gb, lru[0], 5);
>>              g = decode_sym_565(gb, lru[1], is_565 ? 6 : 5);
>> @@ -462,7 +462,7 @@ static int dx2_decode_slice_rgb(GetBitContext *gb,
>> AVFrame *frame,
>>      int stride   = frame->linesize[0];
>>      uint8_t *dst = frame->data[0] + stride * line;
>>
>> -    for (y = 0; y < left && get_bits_left(gb) > 6 * width; y++) {
>> +    for (y = 0; y < left && get_bits_left(gb) >= 3 * width; y++) {
>>          for (x = 0; x < width; x++) {
>>              dst[x * 3 + 0] = decode_sym(gb, lru[0]);
>>              dst[x * 3 + 1] = decode_sym(gb, lru[1]);
>
>> @@ -508,7 +508,7 @@ static int dx2_decode_slice_410(GetBitContext *gb,
>> AVFrame *frame,
>>      uint8_t *U  = frame->data[1] + (ustride >> 2) * line;
>>      uint8_t *V  = frame->data[2] + (vstride >> 2) * line;
>>
>> -    for (y = 0; y < left - 3 && get_bits_left(gb) > 9 * width; y += 4) {
>> +    for (y = 0; y < left - 3 && get_bits_left(gb) >= 4 * width; y += 4)
>> {
>>          for (x = 0; x < width; x += 4) {
>>              for (j = 0; j < 4; j++)
>>                  for (i = 0; i < 4; i++)
>
> iam not sure this is correct
> let us consider the equal case occurs get_bits_left(gb) == 4 * width;
> now this is read as 4x4 blocks, each will read a minimum of 18 bits 16 luma
> and 2 chroma. 18*(width/4) == 4 * width doesnt look right

This is correct and it is for support odd dimensions (not supported at
all from beginning) in next patch, the ones non-aligned to subsampled
constraints.


More information about the ffmpeg-devel mailing list