[FFmpeg-devel] [PATCH v3 2/2] Newtek SpeedHQ decoder.

[Paul B Mahol]

On 1/9/17, Steinar H. Gunderson <steinar+ffmpeg at gunderson.no> wrote:
> On Mon, Jan 09, 2017 at 06:30:52PM +0100, Paul B Mahol wrote:
>>> +/* AC codes: Very similar but not identical to MPEG-2. */
>>> +static uint16_t speedhq_vlc[123][2] = {
>> Can this be uint8_t too?
>
> No, it goes into an RLTable, which expects an uint16_t*. Besides, after
> bit-reversing, several elements are larger than uint8_t can handle.
>
>>> +/* NOTE: The first element is always 16, unscaled. */
>>> +static const uint16_t unscaled_quant_matrix[64] = {
>> This can be uint8_t
>
> It can. Will fix.
>
>>> +static inline int decode_dc_le(GetBitContext *gb, int component)
>>> +{
>>> +    int code, diff;
>>> +
>>> +    if (component == 0 || component == 3) {
>>> +        code = get_vlc2(gb, ff_dc_lum_vlc_le.table, DC_VLC_BITS, 2);
>>> +    } else {
>>> +        code = get_vlc2(gb, ff_dc_chroma_vlc_le.table, DC_VLC_BITS, 2);
>>> +    }
>>> +    if (code < 0) {
>>> +        av_log(NULL, AV_LOG_ERROR, "invalid dc code at\n");
>>> +        return 0xffff;
>> Why this specific return value? I suppose decoding other blocks still
>> continue?
>
> I don't know; this function was cloned from decode_dc(), so I wanted to be
> consistent.

If get_vlc2 fails, and return negative number and this does not cause crash
than patch LGTM.