Opened 2 years ago

Last modified 2 years ago

#6445 new defect

Incorrect Video Levels in vf_colorspace

Reported by: maweber Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords:
Cc: schrebtisch@labor4.ch Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

trying to set the manual definition of image specs right.
video levels seem to be handled incorrectly.
i get "double" videolevels if going from "tv" to "tv", but correct if from "tv" to "pc"

setup:

  • input has video levels (manually set in davinci resolve)
  • input is prores4444 (I think it's neglectable)
  • ffmpeg version git-2017-06-07-1729bf3

this produces INcorrect videolevels:

# "tv" to "tv",.
"$FFBIN" -y  -i "V1-0008-vlevels709.mov" -an -filter_complex "[0:0]setfield=prog[vtmp1],[vtmp1]\
\
colorspace=ispace=bt709:itrc=gamma235:iprimaries=bt709:irange=tv:\
space=bt709:trc=gamma22:primaries=bt709:range=tv:\
format=yuv444p12:dither=fsb:wpadapt=identity\
\
[vtmp2]" -map [vtmp2]   -c:v prores -profile:v 3  -pix_fmt yuv422p10le -b:v 4000k -minrate 4000k -maxrate 4000k -bufsize 1835k  -sn -strict experimental -async 1 -threads 0 "V1-0008-vlevels709-2-io-in-cs--tvtotv.mov"  

this produces CORRECT videolevels:

# "tv" to "pc"
"$FFBIN" -y  -i "V1-0008-vlevels709.mov" -an -filter_complex "[0:0]setfield=prog[vtmp1],[vtmp1]\
\
colorspace=ispace=bt709:itrc=gamma22:iprimaries=bt709:irange=tv:\
space=bt709:trc=gamma22:primaries=bt709:range=pc:\
format=yuv444p12:dither=fsb:wpadapt=identity\
\
[vtmp2]" -map [vtmp2]   -c:v prores -profile:v 3  -pix_fmt yuv422p10le -b:v 4000k -minrate 4000k -maxrate 4000k -bufsize 1835k  -sn -strict experimental -async 1 -threads 0 "V1-0008-vlevels709-2-io-in-cs--tvtopc.mov"  

btw I also get wrong auto outputs if I set input params like

"-color_primaries bt709 -colorspace bt709 -color_range tv -color_trc gamma22"

if "pc" basically means "100%" I would think this is misleading?

Attachments (4)

PR4444_709_lim.mov (1.3 MB) - added by maweber 2 years ago.
the used file in the command
PR4444_709_full.mov (1.3 MB) - added by maweber 2 years ago.
optional
ff-cs-bugreport.txt (8.4 KB) - added by maweber 2 years ago.
Updated bug report, STDOUT and conclusions
cslevels_multiplayout.sh (3.6 KB) - added by maweber 2 years ago.
I created a batch file to precisely evaluate all variations

Change History (9)

comment:1 Changed 2 years ago by maweber

TYPO: sorry for the "gamma235" left in there. overlooked it upon replacing. I guess you can use "gamma22"

comment:2 Changed 2 years ago by cehoyos

Please provide the command line you tested together with the complete, uncut console output and a small input file to make this a valid ticket.

Changed 2 years ago by maweber

the used file in the command

Changed 2 years ago by maweber

optional

Changed 2 years ago by maweber

Updated bug report, STDOUT and conclusions

comment:3 Changed 2 years ago by maweber

Please see the updated bug report in the TXT file.
As I see it, i think I misunderstood the concept due to false positives.
But my suggestions may be worth a thought/ a help for the team anyway.
best, and thanks a lot for your efforts!
manu

comment:4 Changed 2 years ago by maweber

Please allow another question, as it is closely bound to this case:

Example: File has video levels.
Given the decoder has correctly identified the video levels and passes the image to the filter,
What levels are at the beginning of the filter chain?

I ask because I also had difficulties to understand when I used LUTs with full/limited inputs and outputs.

Thanks!

Changed 2 years ago by maweber

I created a batch file to precisely evaluate all variations

comment:5 Changed 2 years ago by maweber

I hope I got this right?
from the batch file:

# Conclusion: ffmpeg version git-2017-06-09-9c6b982
#
# vf_colorspace irange WILL override the input "-color_range",
# vf_colorspace irange is not a factor.
# vf_colorspace range will NOT override the output pix_fmt,
# vf_colorspace range is a factor, will be multiplied by the pix_fmt levels of the encoder

I'm not sure about the way to take it, as I tend to struggle with this kind of complexity.
;-)
Somehow I expected the image beginning at vf to be normalized somehow. The file input params are very useful for GUIs and wrapping applications, so I guess the input params of colorspace are better not used when file input params are present. If using "lut3d" in the chain I guess it's recommended to prefix a vf_colorspace range to normalize it, and have consistent results... (?)

That's as far as I can get for now, thanks anyways for a feedback.
Have a good one,
M

Note: See TracTickets for help on using tickets.