[FFmpeg-devel] [PATCH v2 12/16] swscale/range_convert: fix mpeg ranges in yuv range conversion for non-8-bit pixel formats
Ramiro Polla
ramiro.polla at gmail.com
Sun Sep 29 15:28:52 EEST 2024
On Sat, Sep 28, 2024 at 11:41 PM Michael Niedermayer
<michael at niedermayer.cc> wrote:
> On Fri, Sep 27, 2024 at 02:52:37PM +0200, Ramiro Polla wrote:
> > There is an issue with the constants used in YUV to YUV range conversion,
> > where the upper bound is not respected when converting to mpeg range.
> >
> > With this commit, the constants are calculated at runtime, depending on
> > the bit depth. This approach also allows us to more easily understand how
> > the constants are derived.
> >
> > For bit depths <= 14, the number of fixed point bits has been set to 14
> > for all conversions, to simplify the code.
> > For bit depths > 14, the number of fixed points bits has been raised and
> > set to 18, to allow for the conversion to be accurate enough for the mpeg
> > range to be respected.
> >
> > The convert functions now take the conversion constants (coeff and offset)
> > as function arguments.
> > For bit depths <= 14, offset is 32-bit.
> > For bit depths > 14, offset is 64-bit.
> >
> > x86_64:
> > chrRangeFromJpeg8_1920_c: 5804.5 5845.2 ( 0.99x)
> > chrRangeFromJpeg16_1920_c: 5792.8 5809.1 ( 1.00x)
> > chrRangeToJpeg8_1920_c: 9388.6 9462.2 ( 0.99x)
> > chrRangeToJpeg16_1920_c: 5796.5 9261.5 ( 0.63x)
> > lumRangeFromJpeg8_1920_c: 4147.9 4191.4 ( 0.99x)
> > lumRangeFromJpeg16_1920_c: 4529.0 4143.4 ( 1.09x)
> > lumRangeToJpeg8_1920_c: 5694.1 5720.5 ( 1.00x)
> > lumRangeToJpeg16_1920_c: 5334.2 5139.5 ( 1.04x)
> >
> > aarch64 A55:
> > chrRangeFromJpeg8_1920_c: 28833.8 28834.8 ( 1.00x)
> > chrRangeFromJpeg16_1920_c: 28842.8 28840.6 ( 1.00x)
> > chrRangeToJpeg8_1920_c: 23070.6 23072.5 ( 1.00x)
> > chrRangeToJpeg16_1920_c: 17313.8 23075.1 ( 0.75x)
> > lumRangeFromJpeg8_1920_c: 15388.1 15386.7 ( 1.00x)
> > lumRangeFromJpeg16_1920_c: 15388.0 15383.8 ( 1.00x)
> > lumRangeToJpeg8_1920_c: 19226.2 19223.6 ( 1.00x)
> > lumRangeToJpeg16_1920_c: 19225.5 19225.5 ( 1.00x)
> >
> > aarch64 A76:
> > chrRangeFromJpeg8_1920_c: 6317.8 6318.5 ( 1.00x)
> > chrRangeFromJpeg16_1920_c: 6322.9 6323.5 ( 1.00x)
> > chrRangeToJpeg8_1920_c: 9287.1 9170.0 ( 1.01x)
> > chrRangeToJpeg16_1920_c: 6104.9 9195.6 ( 0.66x)
> > lumRangeFromJpeg8_1920_c: 4359.1 4425.5 ( 0.98x)
> > lumRangeFromJpeg16_1920_c: 4358.8 4436.8 ( 0.98x)
> > lumRangeToJpeg8_1920_c: 5957.2 6017.2 ( 0.99x)
> > lumRangeToJpeg16_1920_c: 6072.5 6017.2 ( 1.01x)
> >
> > NOTE: all simd optimizations for range_convert have been disabled.
> > they will be re-enabled when they are fixed for each architecture.
> >
> > NOTE2: the same issue still exists in rgb2yuv conversions, which is not
> > addressed in this commit.
> > ---
> > libswscale/aarch64/swscale.c | 5 +
> > libswscale/hscale.c | 6 +-
> > libswscale/swscale.c | 103 ++++++++--
> > libswscale/swscale_internal.h | 10 +-
> > libswscale/x86/swscale.c | 5 +
> > tests/checkasm/sw_range_convert.c | 74 ++++++-
> > .../fate/filter-alphaextract_alphamerge_rgb | 100 +++++-----
> > tests/ref/fate/filter-pixdesc-gray10be | 2 +-
> > tests/ref/fate/filter-pixdesc-gray10le | 2 +-
> > tests/ref/fate/filter-pixdesc-gray12be | 2 +-
> > tests/ref/fate/filter-pixdesc-gray12le | 2 +-
> > tests/ref/fate/filter-pixdesc-gray14be | 2 +-
> > tests/ref/fate/filter-pixdesc-gray14le | 2 +-
> > tests/ref/fate/filter-pixdesc-gray16be | 2 +-
> > tests/ref/fate/filter-pixdesc-gray16le | 2 +-
> > tests/ref/fate/filter-pixdesc-gray9be | 2 +-
> > tests/ref/fate/filter-pixdesc-gray9le | 2 +-
> > tests/ref/fate/filter-pixdesc-ya16be | 2 +-
> > tests/ref/fate/filter-pixdesc-ya16le | 2 +-
> > tests/ref/fate/filter-pixdesc-yuvj411p | 2 +-
> > tests/ref/fate/filter-pixdesc-yuvj420p | 2 +-
> > tests/ref/fate/filter-pixdesc-yuvj422p | 2 +-
> > tests/ref/fate/filter-pixdesc-yuvj440p | 2 +-
> > tests/ref/fate/filter-pixdesc-yuvj444p | 2 +-
> > tests/ref/fate/filter-pixfmts-copy | 34 ++--
> > tests/ref/fate/filter-pixfmts-crop | 34 ++--
> > tests/ref/fate/filter-pixfmts-field | 34 ++--
> > tests/ref/fate/filter-pixfmts-fieldorder | 30 +--
> > tests/ref/fate/filter-pixfmts-hflip | 34 ++--
> > tests/ref/fate/filter-pixfmts-il | 34 ++--
> > tests/ref/fate/filter-pixfmts-lut | 18 +-
> > tests/ref/fate/filter-pixfmts-null | 34 ++--
> > tests/ref/fate/filter-pixfmts-pad | 22 +--
> > tests/ref/fate/filter-pixfmts-pullup | 10 +-
> > tests/ref/fate/filter-pixfmts-rotate | 4 +-
> > tests/ref/fate/filter-pixfmts-scale | 34 ++--
> > tests/ref/fate/filter-pixfmts-swapuv | 10 +-
> > .../ref/fate/filter-pixfmts-tinterlace_cvlpf | 8 +-
> > .../ref/fate/filter-pixfmts-tinterlace_merge | 8 +-
> > tests/ref/fate/filter-pixfmts-tinterlace_pad | 8 +-
> > tests/ref/fate/filter-pixfmts-tinterlace_vlpf | 8 +-
> > tests/ref/fate/filter-pixfmts-transpose | 28 +--
> > tests/ref/fate/filter-pixfmts-vflip | 34 ++--
> > tests/ref/fate/fitsenc-gray | 2 +-
> > tests/ref/fate/fitsenc-gray16be | 10 +-
> > tests/ref/fate/gifenc-gray | 186 +++++++++---------
> > tests/ref/fate/idroq-video-encode | 2 +-
> > tests/ref/fate/jpg-icc | 8 +-
> > tests/ref/fate/sws-yuv-colorspace | 2 +-
> > tests/ref/fate/sws-yuv-range | 2 +-
> > tests/ref/fate/vvc-conformance-SCALING_A_1 | 128 ++++++------
> > tests/ref/lavf/gray16be.fits | 4 +-
> > tests/ref/lavf/gray16be.pam | 4 +-
> > tests/ref/lavf/gray16be.png | 6 +-
> > tests/ref/lavf/jpg | 6 +-
> > tests/ref/lavf/smjpeg | 6 +-
> > tests/ref/pixfmt/yuvj420p | 2 +-
> > tests/ref/pixfmt/yuvj422p | 2 +-
> > tests/ref/pixfmt/yuvj440p | 2 +-
> > tests/ref/pixfmt/yuvj444p | 2 +-
> > tests/ref/seek/lavf-jpg | 8 +-
> > tests/ref/seek/vsynth_lena-mjpeg | 40 ++--
> > tests/ref/seek/vsynth_lena-roqvideo | 2 +-
> > tests/ref/vsynth/vsynth1-amv | 8 +-
> > tests/ref/vsynth/vsynth1-mjpeg | 6 +-
> > tests/ref/vsynth/vsynth1-mjpeg-422 | 6 +-
> > tests/ref/vsynth/vsynth1-mjpeg-444 | 6 +-
> > tests/ref/vsynth/vsynth1-mjpeg-huffman | 6 +-
> > tests/ref/vsynth/vsynth1-mjpeg-trell | 8 +-
> > tests/ref/vsynth/vsynth1-mjpeg-trell-huffman | 8 +-
> > tests/ref/vsynth/vsynth1-roqvideo | 8 +-
> > tests/ref/vsynth/vsynth2-amv | 6 +-
> > tests/ref/vsynth/vsynth2-mjpeg | 6 +-
> > tests/ref/vsynth/vsynth2-mjpeg-422 | 6 +-
> > tests/ref/vsynth/vsynth2-mjpeg-444 | 6 +-
> > tests/ref/vsynth/vsynth2-mjpeg-huffman | 6 +-
> > tests/ref/vsynth/vsynth2-mjpeg-trell | 8 +-
> > tests/ref/vsynth/vsynth2-mjpeg-trell-huffman | 8 +-
> > tests/ref/vsynth/vsynth2-roqvideo | 8 +-
> > tests/ref/vsynth/vsynth3-amv | 8 +-
> > tests/ref/vsynth/vsynth3-mjpeg | 8 +-
> > tests/ref/vsynth/vsynth3-mjpeg-422 | 8 +-
> > tests/ref/vsynth/vsynth3-mjpeg-444 | 6 +-
> > tests/ref/vsynth/vsynth3-mjpeg-huffman | 8 +-
> > tests/ref/vsynth/vsynth3-mjpeg-trell | 6 +-
> > tests/ref/vsynth/vsynth3-mjpeg-trell-huffman | 6 +-
> > tests/ref/vsynth/vsynth_lena-amv | 6 +-
> > tests/ref/vsynth/vsynth_lena-mjpeg | 8 +-
> > tests/ref/vsynth/vsynth_lena-mjpeg-422 | 6 +-
> > tests/ref/vsynth/vsynth_lena-mjpeg-444 | 6 +-
> > tests/ref/vsynth/vsynth_lena-mjpeg-huffman | 8 +-
> > tests/ref/vsynth/vsynth_lena-mjpeg-trell | 8 +-
> > .../vsynth/vsynth_lena-mjpeg-trell-huffman | 8 +-
> > tests/ref/vsynth/vsynth_lena-roqvideo | 8 +-
> > 94 files changed, 772 insertions(+), 633 deletions(-)
>
> seems to break fate:
>
> make -j32 fate-filter-owdenoise-sample
> TEST filter-owdenoise-sample
> stddev:12247.77 PSNR: 14.57 MAXDIFF:65280 bytes: 576000/ 576000
> MAXDIFF: |65280 - 1| >= 3539
> Test filter-owdenoise-sample failed. Look at tests/data/fate/filter-owdenoise-sample.err for details.
> make: *** [tests/Makefile:311: fate-filter-owdenoise-sample] Error 1
Ok, I got it now. The reference is in the fate suite samples. That's
why it doesn't show up on git diff after running fate with GEN=1.
It seems to me there is an unnecessary "-color range mpeg" in that
test. But fixing this requires changing both the reference in the fate
suite and the test in tests/fate/filter-video.mak. How can we fix this
without breaking fate for people that haven't run make fate-rsync?
Perhaps disable the test, update the reference, wait a couple of days,
and enable the test again without -color_range? Or just keeping a
resulting checksum in git, so that it can more easily be updated when
needed?
Ramiro
More information about the ffmpeg-devel
mailing list