On 1/9/17, Steinar H. Gunderson <steinar+ffm...@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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
