Opened 20 months ago
Last modified 20 months ago
#9898 reopened defect
Different result using FFmpeg 5.1 and 5.0.1 with -color_trc log / log_sqrt
Reported by: | gabriele_ls | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | unspecified | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description (last modified by )
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
Attachments (3)
Change History (25)
comment:1 by , 20 months ago
Component: | ffmpeg → undetermined |
---|
comment:2 by , 20 months ago
Description: | modified (diff) |
---|
Hello Carl Eugen Hoyos, I modified the command line. There was an unneeded "-o".
by , 20 months ago
Attachment: | console_output_FFmpeg_5.0.1.txt added |
---|
by , 20 months ago
Attachment: | console_output_FFmpeg_5.1.txt added |
---|
comment:3 by , 20 months ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
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.
by , 20 months ago
Attachment: | console_output_FFmpeg_git_head.txt added |
---|
comment:4 by , 20 months ago
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
comment:5 by , 20 months ago
Description: | modified (diff) |
---|---|
Resolution: | invalid |
Status: | closed → reopened |
@Balling, I recommend you to read before commenting. My ticket explains the problem unequivocally.
comment:6 by , 20 months ago
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
You cannot use ffmpeg for S-Gamut3-Gamut3.Cine/S-Log3. We do not support it.
comment:7 by , 20 months ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
Where did you read that I am asking how to use my files with FFmpeg? Please read the title of my ticket.
comment:8 by , 20 months ago
Version: | unspecified → git-master |
---|
comment:9 by , 20 months ago
Version: | unspecified → git-master |
---|
comment:10 by , 20 months ago
Version: | git-master → unspecified |
---|
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.
comment:11 by , 20 months ago
@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.
comment:12 by , 20 months ago
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.
comment:13 by , 20 months ago
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.
comment:14 by , 20 months ago
@Carl Eugen Hoyos read my comments above. I provided what you asked when you asked for it.
comment:15 by , 20 months ago
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.
comment:16 by , 20 months ago
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.
comment:17 by , 20 months ago
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
comment:18 by , 20 months ago
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.
comment:19 by , 20 months ago
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
The different result is expected, please do not reopen this again.
comment:20 by , 20 months ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
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).
comment:21 by , 20 months ago
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?
comment:22 by , 20 months ago
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.
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.