[FFmpeg-devel] [PATCH v2] avcodec/jpeg2000: Add support for High-Throughput JPEG 2000 (HTJ2K) decoding.

Tomas Härdin tjoppen at acc.umu.se
Wed Sep 21 13:30:14 EEST 2022


ons 2022-09-21 klockan 11:13 +0300 skrev Caleb Etemesi:
> > > Please separate struct renaming into a separate patch
> 
> Will do in the next patch
> 
> > > Corresponds to µ_start, right?
> 
> Not sure what  µ_start here relates to, but this is the zero bit
> plane
> information in *B.10.5*
> of the jpeg2000 spec (ITU Rec. T.800 (06/2019))
> 
> > > Could also be called Lcup and Lref. But fine I suppose.
> 
> Will change in the next patch
> 
> > > No time to review this atm, hopefully later though
> 
> No problem.
> 
> 
> > > Why are these tables in here when they're only used by
> > > jpeg2000htdec.c?
> 
> I wasn't aware of any table placing conventions and my personal
> preference
> is usually to place them
> inside header files.

You could have them in a separate file to make the code a bit easier to
read, but keeping them in a file that's included by both decoders is
kinda wrong. The compiler won't put them into the regular j2k decoder's
.o file since it doesn't use them, but still.

Tested this locally on some 4k sample files and it achieved 19 fps with
-lowres 2 on an Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz (4 cores). I'm
getting access to a better machine to test this on as well.

I will probably spend some time getting this to work with the improved
threading patchset I've posted on here, once the new mem.* stuff is in.
Hopefully that brings realtime 4k htj2k decoding to threadripper and
similar CPUs, with low seek latency thanks to slice threading. That
would bring ffmpeg's decoder "ahead" of libopenjpeg, since opj only
does threading on slice (maybe precinct) level not codeblock level

/Tomas



More information about the ffmpeg-devel mailing list