extractplanes=y produces garbage with gray10 input

[Diederick Niehorster]

I have a file with gray10le frames in them. While pointless in a way, running extractplanes=y filter on them produces garbage:

ffmpeg.exe -y -i test.mkv -vf extractplanes=y -frames:v 1 nhcvbqaw.png

The following simpler command works fine

ffmpeg.exe -y -i test.mkv -frames:v 1 nhcvbqaw.png

While its pointless to extract the luma plane from a frame that only has a luma plane, i guess it should work? Input and output files are attached.

full output:

ffmpeg.exe -y -i test.mkv -vf extractplanes=y -frames:v 1 nhcvbqaw.png
ffmpeg version 2021-12-27-git-617452ce2c-full_build-www.gyan.dev Copyright (c) 2000-2021 the FFmpeg developers
  built with gcc 11.2.0 (Rev2, Built by MSYS2 project)
  configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-sdl2 --enable-libdav1d --enable-libdavs2 --enable-libuavs3d --enable-libzvbi --enable-librav1e --enable-libsvtav1 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libshaderc --enable-vulkan --enable-libplacebo --enable-opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libilbc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable-libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint
  libavutil      57. 13.100 / 57. 13.100
  libavcodec     59. 15.101 / 59. 15.101
  libavformat    59. 10.100 / 59. 10.100
  libavdevice    59.  1.100 / 59.  1.100
  libavfilter     8. 21.100 /  8. 21.100
  libswscale      6.  1.102 /  6.  1.102
  libswresample   4.  0.100 /  4.  0.100
  libpostproc    56.  0.100 / 56.  0.100
Input #0, matroska,webm, from 'test.mkv':
  Metadata:
    ENCODER         : Lavf59.10.100
  Duration: 00:00:00.02, start: 0.000000, bitrate: 1142412 kb/s
  Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), gray10le(pc), 1152x390, 500 fps, 500 tbr, 1k tbn (default)
    Metadata:
      DURATION        : 00:00:00.018000000
Stream mapping:
  Stream #0:0 -> #0:0 (ffv1 (native) -> png (native))
Press [q] to stop, [?] for help
Output #0, image2, to 'nhcvbqaw.png':
  Metadata:
    encoder         : Lavf59.10.100
  Stream #0:0: Video: png, gray16be(pc, progressive), 1152x390, q=2-31, 200 kb/s, 500 fps, 500 tbn (default)
    Metadata:
      DURATION        : 00:00:00.018000000
      encoder         : Lavc59.15.101 png
frame=    1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.00 bitrate=N/A speed=0.0193x
video:463kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

[Diederick Niehorster]

input file

[Diederick Niehorster]

garbage output

[Balling]

The other problem is that in ffplay 10 bit is incorrectly presented for extractplanes, overexposed and in a different way that to png (compared to ffmpeg). That happens in many other cases too, not only gray10. 8 bit works perfectly always.

See for yourself: ffplay.exe -i test.mkv -vf extractplanes=y

[Elon Musk]

Fixed in da473e0984e0ee3d99c4677c74b2acf62e91caaa

[Balling]

Yep, fixed. Just for posterity "While it's pointless to extract the luma plane from a frame that only has a luma plane" is false. The whole point of extractplanes is to extract the bits as they are in the source format. That means that YCbCr (or Y only) conversion to R'G'B' does not happen. Yes, it so happens that (limited) Y only grayscale can be presented as (again, limited) R = G = B = Y, but that may be not the case in ICtCp or if color managment happens. And it is not the case in full range Y and full range R'G'B' (ffmpeg only supports full range R'G'B' anyway). Also, the Paul's code preserves superblack and superwhite for limited range and allows to analyse out-of-R'G'B'-gamut stuff for full range YCbCr.

Ah, also png produced that way is not tagged in any way (so is perfect sRGB), and you can create many crazy stuff with this.