Incorrect color interpretation when streaming via WebRTC

[wanderingcode]

Since upgrading to OBS 28 the video color is lifted when streaming with WebRtc.
If I switch the stream to Millicast RTMP then the colors are accurate. This was not an issue with OBS 27.2.4 via WebRTC.

In the photos below, the top color chart is Resolve which is the source. That's fed through a Black Magic UltraStudio Mini and received into OBS via a BLack Magic UltraStudio Mini. The bottom color chart is the received stream in a web browser. See the photos below to highlight the color shift when using WebRTC.

Streaming via RTMP

Streaming via WebRTC

[ludocosmo]

Hi,

I also notice a difference in colors, but it happens both for RTMP and WebRTC for version 27.2.4 as well as for 28.1.2.

Settings:

• codec h.264 for WebRTC
• colour format I420
• colour space Rec. 709
• colour range limited
• SDR while level 300 nits
• HDR nominal peak level 1000 nits

I stream using the following static image as source:

Received image displayed in Chrome 109.0.5414.119

• sent from OBS 27.2.4 using WebRTC

• sent from OBS 27.2.4 using RTMP

• sent from OBS 28.1.2 using WebRTC

• sent from OBS 28.1.2 using RTMP

Received images are identical, whether they have been streamed using RTMP or WebRTC, OBS 27.2.4 or OBS 28.1.2. There is a color difference from the original static image.

[ludocosmo]

Trying to stream the same static image to Facebook using regular OBS.

Settings:

• colour format NV12
• colour space Rec. 709
• colour range limited
• SDR while level 300 nits
• HDR nominal peak level 1000 nits

Source image:

Received image displayed in Facebook in Chrome 110.0.5481.177

• sent from OBS 27.2.4

• sent from OBS 28.1.2

• sent from OBS 29.0.2

For comparison, this is the image received in Chrome when streaming from OBS WebRTC 28.1.2:

There is a color difference from the original static image, both when streaming using regular OBS and WebRTC OBS.

[ludocosmo]

I am able to get a slight difference in colour rendering by selecting a different colour format.

This is my source static image:

Streaming using colour format I420 (no difference when streaming with WebRTC, RTMP, OBS 27.2.4 and 28.1.2)

We can notice that:

• greys are identical (696969 and c1c1c1) in source image and on the streamed image
• yellow, cyan, green, magenta, red and blue are all slightly different between source image and streamed image

Streaming using colour format NV12

We can notice that there is a tiny difference for cyan and green when using colour format NV12 or I420.

============= Here is what happens for your streaming.

Your source image:

Streaming with RTMP:

We can notice that all colours and greys are different between source image and streamed image.

Streaming with WebRTC:

We can notice that all colours and greys are different between RTMP streamed image and WebRTC streamed image.

What are your settings (colour format, colour range, codec):

• for streaming with RTMP?
• for streaming with WebRTC?

[wanderingcode]

In our tests the following combo has always produced accurate results and my tests were run with:

codec: VP8 ColorSpace: Rec 601 Pixel Format: NV12 Color Range: Partial (On OBS 28) SDR White Level 300 nits HDR Peak Level 1000 Nits

From your FB tests it looks like this may be an issue in the original OBS and not the WebRTC implementation?

Using these settings I see accurate color reproduction in OBSWebRTC-27.2.4, but not in V28.

The screenshots below shows OBS window on the bottom, and Chrome 110.0.5481.177 on top. Running on MacOS 13.2.1

Below is a screen shot using OBS-WebRTC 27.2.4 (Release 1.3.2)

And here is a screen shot with OBSWebRTC-28.1.1

[ludocosmo]

I reproduced the problem with your settings.

Source image:

Stream from OBS 1.3.2-27.2.4:

Stream from OBS 1.4.1-28.1.1:

Key setting is color space: Rec 601 With color space 709, received images from streaming with OBS 27 and OBS 28 are identical. But with color space 601, received images from streaming with OBS 27 and OBS 28 are different as shown above.

I am investigating the origin of this difference for color space 601.

[wanderingcode]

Thank you for your efforts on this. VP8 spec lists Rec601 as the correct color space, and so far that's the only way I've been able to get accurate color rendering is with the above settings.

I never fully understood why h264 and other codecs don't render the colors correctly in this workflow. (Side note) So far I haven't found a listed color space in the specs for VP9 or AV1. If you happen to see those anywhere I'd love to discover that!

The problem is in OBS 28 Rec601 is no longer is accurate. At first I thought it was incorrectly using Rec701 color space, but my tests show a different color rendering for 601 and 709, both of which are incorrect.

In these photos, top row is via chrome, middle row is OBS window, and bottom row is the source PNG I used.

OBS 27.2.4 Rec601:

OBS 27.2.4 Rec709:

OBS 28.1.1 Rec601:

OBS 28.1.1 Rec709:

[ludocosmo]

I confirm there is an issue in OBS 28 about color space 601. I saved raw frames delivered by OBS before encoding to compare them.

• In OBS 27, color space 601, raw frames delivered to RTMP are IDENTICAL to raw frames delivered to WebRTC.
• In OBS 28, color space 601, raw frames delivered to RTMP are DIFFERENT from raw frames delivered to WebRTC.
• In OBS 28, color space 709, raw frames delivered to RTMP are IDENTICAL to raw frames delivered to WebRTC.
• Raw frames color space 601 of OBS 27 delivered to RTMP are DIFFERENT from raw frames color space 601 of OBS 28 delivered to RTMP.
• Raw frames color space 709 of OBS 27 delivered to RTMP are DIFFERENT from raw frames color space 709 of OBS 28 delivered to RTMP.
• Raw frames color space 601 of OBS 27 delivered to WebRTC are DIFFERENT from raw frames color space 601 of OBS 28 delivered to WebRTC.
• Raw frames color space 709 of OBS 27 delivered to WebRTC are DIFFERENT from raw frames color space 709 of OBS 28 delivered to WebRTC.

Color management in OBS 28 has been modified a lot as compared to OBS 27. I have not yet identified how they changed management of color space for delivery of raw frames to encoder.

[wanderingcode]

Thank you for doing the raw frame comparison. Let me know if there is more I can do to help discover the root of the issue.

[ludocosmo]

Root of the issue has been identified as a difference in default format of raw frames to be delivered to libwebrtc for encoding.

• Until OBS 27: no assumption of default format of raw frames: they are delivered directly to libwebrtc.
• From OBS 28: raw frames are assumed to be of color format NV12 / color space Rec. 709 / color range Limited. If the user selects anything different from the default format, OBS performs a conversion from default format to the format selected by the user before delivering the frame to libwebrtc. Hence, since OBS 28, when you select color space Rec. 601 (which is different from OBS 28 default format Rec. 709), OBS performs a conversion of current raw frame from default Rec. 709 to user selected Rec. 601 before delivering the frame to libwebrtc. A future release of OBS-WebRTC will revert back to OBS 27 behaviour: Make no assumption on raw frames default format and deliver them directly to libwertc without any conversion.

[wanderingcode]

Excellent! Thank you so much for your efforts in tracking this down and getting it corrected.

[wanderingcode]

Any word on when this fix will be implemented? Thanks