rav1e.exe --content-light (0,0) "thread 'main' panicked"

[Joachim-Otahal]

Versions:
rav1e 0.6.3 (v0.6.3) (release)
ffmpeg version 6.0-full_build-www.gyan.dev.
Windows 11 21h2 (though that does not matter here)

I am not sure whether this is actually me using the option wrong or whether rav1e is at fault here.

1 second source video to reproduce and test: https://joumxyzptlk.de/tmp/10-bit-input.mkv

Full command line which failes:

ffmpeg.exe -hide_banner -loglevel quiet -i "10-bit-input.mkv" -an -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | rav1e-ch.exe -  --speed 4  --quantizer 120 --primaries bt2020 --transfer smpte2084 --mastering-display G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(1,10000000) --content-light (0,0) -y --output "10-bit-input.ivf"
!  Chromaticity coordinates will be trimmed to the range 0.0 to 1.0 (see AV1 spec sec. 6.7.4).
thread 'main' panicked at 'Cannot parse the content light option: ScanError("parse::u16")', src\bin\common.rs:634:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Full command line without --content-light works and produces correct output - well, the color information is interpreted correctly by my player at least:

ffmpeg.exe -hide_banner -loglevel quiet -i "10-bit-input.mkv" -an -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | rav1e-ch.exe - --speed 4 --quantizer 120 --primaries bt2020 --transfer smpte2084 --mastering-display G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(1,10000000) -y --output "10-bit-input.ivf"

With trace:

C:\tmp>set RUST_BACKTRACE=full

C:\tmp>ffmpeg.exe -hide_banner -loglevel quiet -i "10-bit-input.mkv" -an -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | rav1e-ch.exe -  --speed 4  --quantizer 120 --primaries bt2020 --transfer smpte2084 --mastering-display G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(1,10000000) --content-light (0,0) -y --output "10-bit-input.ivf"
!  Chromaticity coordinates will be trimmed to the range 0.0 to 1.0 (see AV1 spec sec. 6.7.4).
thread 'main' panicked at 'Cannot parse the content light option: ScanError("parse::u16")', src\bin\common.rs:634:10
stack backtrace:
   0:     0x7ff7d635b71c - <unknown>
   1:     0x7ff7d62f250b - <unknown>
   2:     0x7ff7d634b3ca - <unknown>
   3:     0x7ff7d635d40b - <unknown>
   4:     0x7ff7d635d001 - <unknown>
   5:     0x7ff7d635df1d - <unknown>
   6:     0x7ff7d635d9d5 - <unknown>
   7:     0x7ff7d635d91f - <unknown>
   8:     0x7ff7d635d8f4 - <unknown>
   9:     0x7ff7d64056c5 - <unknown>
  10:     0x7ff7d64059a3 - <unknown>
  11:     0x7ff7d62301a0 - <unknown>
  12:     0x7ff7d6251e01 - <unknown>
  13:     0x7ff7d60c1866 - <unknown>
  14:     0x7ff7d60c2d92 - <unknown>
  15:     0x7ff7d634acc8 - <unknown>
  16:     0x7ff7d627f20a - <unknown>
  17:     0x7ff7d63f5f3c - <unknown>
  18:     0x7ffbf6f755a0 - BaseThreadInitThunk
  19:     0x7ffbf86c485b - RtlUserThreadStart

[quietvoid]

The option shouldn't have parentheses, it should be --content-light 0,0

[Joachim-Otahal]

Thank for the lightning fast response.
Yep, without the parentheses it works. But it should not crash.
And rav1e.exe --help is misleading:

--content-light <CONTENT_LIGHT>
          Content light level used to describe content luminosity (cll,fall)

Should I close this bug or leave it open? My problem is solved, but a crashing process is not nice.

[quietvoid]

I guess the help message should probably be clearer.

[Joachim-Otahal]

The mastering display options does give an example, should be easy to add a similar text to --content-light:

--mastering-display <MASTERING_DISPLAY>
          Mastering display primaries in the form of G(x,y)B(x,y)R(x,y)WP(x,y)L(max,min)

Or change the --content-light option itself to match the style of --mastering-display