>> 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.

Can this be fixed?

Decoding sauna-cut.jph errors out with

Post 14864313 too big which corresponds to
https://github.com/FFmpeg/FFmpeg/blob/db73ae0dc114aa6fae08e69f977944f056a24995/libavcodec/jpeg2000dec.c#L838-L841

I've tested with RGB samples only, but ffmpeg logs show that it is picking
the format as yuv for the attached image ([format @ 0x55d54132e880] Setting
'pix_fmts' to value 'yuvj420p|yuvj422p|yuvj444p')


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

Should partial files lead to panics?

Using `head  -c 10000 t1.j2c  &> t5.j2c` and followed by ffmpeg decoding
complains with the same error on Psot being too big. I didn't touch that
part


Also as to how the decoder is written, partial files should cause an
`av_assert()` for worst case or decode to invalid data for best case,
hence I might need some clarity on what the decoder "not liking partial
files" means

Attached t1.j2c

Kind regards


On Thu, Sep 22, 2022 at 12:15 PM Tomas Härdin <tjoppen@acc.umu.se> wrote:

> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>