tor 2022-09-22 klockan 07:07 +0300 skrev Caleb Etemesi:
> There is one with way better performance on its way, especially with
> images
> with magnitude refinement passes.
> 
> here @https://github.com/etemesi254/FFmpeg/tree/my-profile
> 
> And the associated runtime profile from running
> 
> `perf record -g -F 999 ./ffmpeg_g  -i ~/jpeg2000/meridian.ht.j2c  -v
> 32
>  -bench
> mark -f null  -`
> 
> Online version  - https://share.firefox.dev/3C0rI9e
> 
> Image -
> https://etemesi254.github.io/assets/imgs/gsoc/meridian.ht.j2c [ 4K
> image]
> 
> Ffmpeg results from the benchmark
> 
> `
> bench: utime=0.371s stime=0.036s rtime=0.408s
> bench: maxrss=165900kB
> `
> The machine is an AMD Ryzen 6000U with 6 cores 128kb L1.
> 
> Perf reports it takes 826 ms,  because the decoder does two decodes
> per
> image,(I think one for the demuxer then the decoder, probably a bug).
> anf most of the time is spent on idwt

Yeah this is due to the way probing in lavf works. When I did
development on the Part 1 decoder I dummied out the first decode, which
always runs at full resolution btw, regardless of what -lowres is set
to.

Have you tested your patch with YUV samples or only RGB? For lossless
RGB it seems to work fine, even when roundtripping back through
OpenJPH. That is, using your decoder on files encoded losslessly with
OpenJPH and then encoding with OpenJPH again yields the exact same
bitstream (except the version number of OpenJPH in the header, 0.7.3 vs
0.9.0 for my samples)

I'm currently trying to convert one of SVT's open samples from Part 1
to Part 15, but unfortunately either OpenJPH isn't writing the right
metadata to say that is it YUV or your code is not probing the pixel
format correctly:

ftp://svtopencontent.svt.se/pub/svt_videotestsuite_natural_complexity/REC709/smoke_sauna_JPEG2000_SDR_3840x2160p50_YUV444_12bit_Lossless.mov

ffmpeg -i
smoke_sauna_JPEG2000_HDR_REC2100_3840x2160p50_YUV444_12bit_Lossless.mov
-vframes 1 sauna-yuv444p12le.yuv
ojph_compress -reversible true -dims '{3840,2160}' -num_comps 3 -signed
false -bit_depth 12 -downsamp '{1,1}' -i sauna-yuv444p12le.yuv -o
sauna.jph

Input vs output:
  Stream #0:0[0x1]: Video: jpeg2000 (JPEG 2000 codestream restriction
0) (mjp2 / 0x32706A6D), yuv444p12le(bt2020nc/bt2020/smpte2084,
progressive), 3840x2160, lossless, 5543461 kb/s, SAR 1:1 DAR 16:9, 50
fps, 50 tbr, 12800 tbn (default)
  Stream #0:0: Video: jpeg2000, rgb48le(12 bpc), 3840x2160, lossless,
25 fps, 25 tbr, 25 tbn

Transcoding the .jph to .png 

I have attached the first 64k of sauna.jph for everyone's sleuthing
benefits. I decoded, downscaled and encoded it to jpeg, see attachment.
It is what you'd expect when YUV is mistaken for RGB.

Your decoder doesn't seem to like partial files btw.

/Tomas