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 produces that way is not tagged in any way, and you can create many crazy stuff with this.