Different result using FFmpeg 5.1 and 5.0.1 with -color_trc log / log_sqrt

[gabriele_ls]

I'm using FFmpeg to convert some video files shot in Slog3 with a Sony A7S III camera. I just discovered that I get different results using the command below on FFmpeg versions 5.1 and 5.0.1.

This is the command I'm using:

% ffmpeg -i input -map 0:0 -map 0:1 -c:a aac -ab 320k -c:v libx264 -crf 15 -s 960x540 -pix_fmt yuv422p10le -profile:v high422 -preset fast -g 1 -color_trc log_sqrt -color_range jpeg output

I'm on Windows 10, and I'm using the builds coming from CODEX FFMPEG (​https://www.gyan.dev/ffmpeg/builds/).

You can see an animated comparison of the results I'm getting here: ​https://dsc.cloud/3c482e/animated_comparison.gif.

You can download sample input and output files here: ​https://we.tl/t-QtYyIdvoEV

[Carl Eugen Hoyos]

The command line you posted does not look usable.
Are you reporting a regression (does current FFmpeg git head produces broken output but an older version worked correctly)? Or do you expect that all versions of FFmpeg produce identical output for a given command line?
Please understand that there is no user support for releases, only for current FFmpeg git head.
Please provide the command line you tested together with the complete, uncut console output to make this a valid ticket.

[gabriele_ls]

Hello Carl Eugen Hoyos, I modified the command line. There was an unneeded "-o".

[Balling]

log_sqrt is described in ITU-T H.273 and has nothing to do with Slog3, Slog2 or panasonic V-Log or Leica L-Log.

Logarithmic transfer characteristic (100 * Sqrt( 10 ) : 1 range) is described here: ​https://www.itu.int/rec/T-REC-H.273-202107-I/en

sLog3 is here: ​https://pro.sony/s3/cms-static-content/uploadfile/06/1237494271406.pdf

L-Log is here: ​https://leica-camera.com/sites/default/files/pm-65977-210914__L-Log_Reference_Manual_EN.pdf

You must use those, fully and correctly implemented here: ​https://github.com/colour-science/colour/pull/338

NEVER USE 3DLUTs for this!! 3DLUTs are only for calibration.

Use Davinci, it allows to just right click on file and select the transfer function.

[Balling]

In fact even mpv only supports slog1 and slog2, not slog3. ​https://github.com/mpv-player/mpv/blob/6265724f3331e3dee8d9ec2b6639def5004a5fa2/video/csputils.c#L91

I also think this is S-Gamut3.Cine/S-Log3, not S-Gamut3/S-Log3.

​https://pro.sony/s3/cms-static-content/uploadfile/06/1237494271406.pdf

[gabriele_ls]

@Balling, I recommend you to read before commenting. My ticket explains the problem unequivocally.

[Balling]

You cannot use ffmpeg for S-Gamut3-Gamut3.Cine/S-Log3. We do not support it.

[gabriele_ls]

Where did you read that I am asking how to use my files with FFmpeg? Please read the title of my ticket.

[Balling]

You can use 3DLUT for it from sony site. Ffmpeg supports 3DLUTs. Of course then there is no point in filming in slog3.

I am [not] asking how to use my files with FFmpeg

Then we will not support you. I said WE DO NOT SUPPORT slog3. Every command you used before with color_trc was wrong. Full stop.

[gabriele_ls]

@Balling, what part of "Different result using FFmpeg 5.1 and 5.0.1" do you find difficult to understand?

I'm an FFmpeg user since 2004. I'm not asking you for advice about how to use it.

[Carl Eugen Hoyos]

Are you reporting a regression (does current FFmpeg git head produces broken output but an older version worked correctly)? Or do you expect that all versions of FFmpeg produce identical output for a given command line?
Please understand that there is no user support for releases, only for current FFmpeg git head.

[Carl Eugen Hoyos]

And PLEASE provide a working command line together with the complete, uncut console output, this would give an interested developer at least a chance to understand what you are doing.

[gabriele_ls]

@Carl Eugen Hoyos read my comments above. I provided what you asked when you asked for it.

[Balling]

ffplay.exe "CAM1_20220823_2907_Proxy FFmpeg 5.1 log.mp4" -vf scale=in_range=tv

fixes the problem, so it is just a wrong tag

ffmpeg -i input -map 0:0 -map 0:1 -c:a aac -ab 320k -c:v libx264 -crf 15 -s 960x540 -pix_fmt yuv422p10le -profile:v high422 -preset fast -g 1 -color_trc log_sqrt -color_range tv output

I am only a developer of ffmpeg since 2019.

If you need BT.709 and PC color range the command is completly wrong.

Only mpv supports log_sqrt decoding, so dunno what you are trying to do. This is just wrong.

[gabriele_ls]

Your command doesn't fix the problem at all. The result you achieve with FFmpeg 5.0.1 differs from that you achieve with the FFmpeg git head. Moreover, the result you achieve with FFmpeg 5.0.1 is identical to the source file, while the one you achieve with the FFmpeg git head is not.

As said, reading is a crucial step in the process of understanding something written. And it looks like you can't do that.

[Balling]

The result you achieve with FFmpeg 5.0.1 differs from that you achieve with the FFmpeg git head

Because of e645a1ddb90a863e129108aad9aa7e2d417f3615, after all your original file is full range. This was just a bug in ffmpeg, see #9576 (full range of a file was being recognized as limited in some cases). Compare your original file with ffplay before and after that commit:

ffplay.exe CAM1_20220823_2907.MP4

This can also make it obvious:

ffmpeg -i CAM1_20220823_2907.MP4 -map 0:0 -map 0:1 -c:a aac -ab 320k -c:v libx264 -crf 15 -s 960x540 -vf scale=in_range=tv:out_range=pc -pix_fmt yuv422p10le -profile:v high422 -preset fast -g 1 -color_trc log_sqrt -color_range jpeg output1.mp4

[gabriele_ls]

Once again, you are writing things completely unrelated to my ticket.

Isn't there any rule about how to properly behave on this platform? Is anyone allowed to spam with nonsense? I guess this is going to prevent any proper bug fixing.

[Balling]

The different result is expected, please do not reopen this again.

[gabriele_ls]

The different result is not expected, and it is not correct.

The FFmpeg 5.0.1 behavior is correct (the input and output files are identical), and the FFmpeg 5.1 behavior is incorrect (the input and output files are not identical).

[Balling]

The FFmpeg 5.0.1 behavior is correct (the input and output files are identical), and the FFmpeg 5.1 behavior is incorrect (the input and output files are not identical).

What matters is applying correct transfer and primaries on your original file: ​https://imgur.com/dZpH9xj

This is screenshot from Davinci and is color managed to BT.709 (so gamma 2.4) scene + BT.709 primaries from your s-gamut3-cine + s-log3-cine file. Again, this is the way to do it.

Again, check e645a1ddb90a863e129108aad9aa7e2d417f3615.
You are not color managing the image, so what are you expecting?

[gabriele_ls]

Could you please stop bothering me? I reported a bug. You have been talking nonsense for the last 5 hours. The title of my ticket describes the bug. Your comments describe an obvious inability to understand a written text. You have a cognitive problem, and I have nothing to do with it. There is nothing more to add.

[Balling]

I found out that Adobe color managment has a bug: it sees incorrectly this as limited range. ​https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=180349&start=50#p1020106

slog3.cine + slog3 is nowadays even recognized as RAW (even though it is anything but) after Davinci 18.5.

​https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=205365&p=1066675&hilit=Sony+raw#p1066675

​https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=180492

​https://forum.blackmagicdesign.com/viewtopic.php?f=38&t=180349

And ​https://youtu.be/USJwrJNTYuM
​https://youtu.be/Q6FyhRfjzuM

[MasterQuestionable]

͏    Well, the jocular havoc that the relevant standards wreaked:
͏    Each implementation making their own interpretation arbitrarily and things displayed randomly across implementations...
͏    For something that probably shouldn't exist in the first place.