Re: [FFmpeg-devel] [PATCH] avcodec: ViewQuest VQC decoder

[Andreas Rheinhardt <andreas.rheinhardt@outlook.com>]

Tomas Härdin:
> fre 2022-10-07 klockan 12:38 +0200 skrev Andreas Rheinhardt:
>> Tomas Härdin:
>>> tor 2022-10-06 klockan 21:45 +1100 skrev Peter Ross:
>>>>
>>>> +static av_cold int vqc_decode_init(AVCodecContext * avctx)
>>>> +{
>>>> +    static AVOnce init_static_once = AV_ONCE_INIT;
>>>> +    VqcContext *s = avctx->priv_data;
>>>> +
>>>> +    s->vectors = av_malloc((avctx->width * avctx->height * 3) /
>>>> 2);
>>>> +    if (!s->vectors)
>>>> +        return AVERROR(ENOMEM);
>>>> +
>>>> +    s->coeff = av_malloc(2 * avctx->width * sizeof(int16_t));
>>>> +    if (!s->coeff)
>>>> +        return AVERROR(ENOMEM);
>>>> +
>>>> +    s->tmp1 = av_malloc(avctx->width * sizeof(int16_t) / 2);
>>>> +    if (!s->tmp1)
>>>> +        return AVERROR(ENOMEM);
>>>> +
>>>> +    s->tmp2 = av_malloc(avctx->width * sizeof(int16_t) / 2);
>>>
>>> av_malloc_array() perhaps? Not that these are likely to overflow
>>> since
>>> max pixels is usually far away from INT_MAX
>>>
>>
>> Actually, sizeof(int16_t) is guaranteed to be two, so that
>> sizeof(int16_t) / 2 is always one.
> 
> Not on machines where CHAR_BIT >= 16. But we could enforce that during
> configuration
> 

The fixed-wide integers are required by the spec to have no padding. We
rely on uint8_t/int8_t to be present and so CHAR_BIT divides 8, but it
has to be >= 8, too, so it is eight. (Apart from that, we probably rely
on CHAR_BIT to be eight in thousands of other places, too.)

- Andreas

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".