Incorrect Video Levels in vf_colorspace

[maweber]

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?

[maweber]

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

[Carl Eugen Hoyos]

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.

[maweber]

the used file in the command

[maweber]

optional

[maweber]

Updated bug report, STDOUT and conclusions

[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

[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!

[maweber]

I created a batch file to precisely evaluate all variations

[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