[FFmpeg-devel] [PATCH] avcodec/cbs_jpeg: Fix size of huffman symbol table array
Andreas Rheinhardt
andreas.rheinhardt at outlook.com
Sat Apr 30 21:38:37 EEST 2022
Mark Thompson:
> On 08/02/2022 09:41, Andreas Rheinhardt wrote:
>> L[i] can be in the range of 0-255, see table B.5 of ITU T.81.
>>
>> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at outlook.com>
>> ---
>> libavcodec/cbs_jpeg.h | 2 +-
>> libavcodec/cbs_jpeg_syntax_template.c | 4 ++--
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> Do you have a valid file showing this? Not all values are allowed.
>
Where is this said in the spec?
The file jpg/12bpp.jpg from the FATE-suite triggers this. It has a
Huffman table with 226 entries.
(Sorry, should have mentioned the sample in the commit message.)
> I guess I must have written it, but I have no idea where 224 came from.
> As far as I know the worst case is in AC tables: 10 category values * 16
> run lengths + 2 special cases = 162 (which could indeed all be dumped in
> the same code length if you want to be pathological).
I have never heard of these restrictions. Would you care to elaborate
which part of the spec they refer to?
Anyway, IIRC there is no restriction against duplicates in the Huffman
table, so one could use even more than 256 values (i.e. there might be
spec-compliant pictures that are not supported by both our decoder and
the current version of cbs_jpeg); it just makes no sense. Notice that
the sample mentioned above has no duplicate values in any Huffman table.
- Andreas
More information about the ffmpeg-devel
mailing list