Server: Decklink producer wrong colorspace

[premultiply]

When passing live video through the server it looks like the colorspace conversion from Decklink HD-SDI Input to internal RGB processing is not BT.709 but BT.601 so color levels and values are shifted.

Tested by passing a simple 1080i5000 color bar from generator through the server to a waveform monitor.

[TomKaltz]

d99ad73af7c03ff584f80d08d366bab0b675357b

[premultiply]

What should this change?

[ronag]

I think @TomKaltz wanted to refer to https://github.com/CasparCG/server/commit/88740587f6d0eb2adc1158f35e483c805dfcea07

But as you indicated on Slack that didn't seem to help,,,

[premultiply]

Yes. It does not help.
But I think it may be possible by using colorspace filter and iall option to overwrite the wrong assumed input properties

or

if possible do the correction/conversion and scaling in one step using scale at the output of the ffmpeg chain right in front of buffersink.

[premultiply]

Using ffmpeg to scale the video to the channel resolution (and convert to RGBA from the correct color properties) has the benefit that any input size would be possible which seems to be limited to 1:1 right now. This prevents ffmpeg from auto inserting a wrong scale filter.

Using swscale is the prefered and best quality method
https://trac.ffmpeg.org/wiki/colorspace

[premultiply]

My theory is validated by running colorspace filter:
PLAY 1 DECKLINK 1 VF colorspace=iall=bt709:all=bt709
gives correct results for HD-SDI input but should be replaced by proper scaler solution.

[ronag]

Pushed to master. If someone can build it for you please test it. @dotarmin is autobuild up and running?

[dotarmin]

Yes it is but I haven't enabled upload to builds.casparcg.com just yet. I plan to do it after lunch today and announce at forum as well.

[premultiply]

https://github.com/CasparCG/server/commit/1aa8a8fa4bfa42e18cfe0641660705931b7313a4
Should work for HD input now but is far away from a final and clean solution.

[ronag]

@premultiply yep, there is a nice TODO waiting for a PR ;)

[ronag]

Since it is possible to workaround (VF) I think for now we can add an entry to the wiki.

[ronag]

I wish the decklink api could tell us what is the correct color space.

[ronag]

@premultiply slightly better implementation pushed. Though the SDK does not have any flags for bt2020.

[premultiply]

Better but the main problem is the colorspace filter itself. Now the colorspace may be converted two times.
First time is from YUV to YUV and second time from YUV to RGB(A). It should be done in single step during the YUV to RGB(A) conversion.

And I am still not shure how this last step is done in current implementation.

I am familiar with all those broadcast standards, workflows, quality, measurements and I can read most of the C++ code but I am not able to high perfomance coding in C++.

[ronag]

@premultiply the colorspace filter in this case does no conversion, it only sets the proper metadata fields on the frames, i.e. it basically does this https://github.com/CasparCG/server/commit/1aa8a8fa4bfa42e18cfe0641660705931b7313a4 but correct.

[premultiply]

Fixed for the moment.

TODO:

• Wait for Decklink SDK to provide BT.2020 indication and add this.
• Switch to „manual“ scale-Filter for proper support of independant input resolutions.
• Check if Decklink SDK supports pre-converted RGB-handover to ffmpeg.