You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
bugSomething isn't workingencodingAudio or video encoders but not the OS interfacesfundingRequires funding to implementhelp wantedExternal contribution is requiredinterfaceOS input, display, or audio interfacesupstreamRequires upstream development from dependencies
There is an incorrect color issue (reproduced in the above issues) where it is concentrated on the video converter.
Other than the video converter, color is consistent between the source (videotestsrc or ximagesrc so no issue here), the encoder (consistent color when the same video converter is used), and output (file and WebRTC video are also consistent color).
cudaconvert and videoconvert are similarly wrong for the colors, but show slightly different ways of being wrong.
Therefore, this is an upstream color converter issue that needs to be fixed in GStreamer.
If this is not fixed, users will have a noticeable feeling of degradation of the remote screen's color reproduction.
At least in flat, single-color, static regions, the reproduction should not deviate outside +/- 1 for each RGB color and converge to the exact color when some time passes in a static state. Thus, luma should be independent of chroma changes.
The text was updated successfully, but these errors were encountered:
ehfd
added
bug
Something isn't working
help wanted
External contribution is required
upstream
Requires upstream development from dependencies
funding
Requires funding to implement
encoding
Audio or video encoders but not the OS interfaces
interface
OS input, display, or audio interfaces
labels
Jun 12, 2024
ehfd
changed the title
Color is incorrect from the GStreamer video converter
Color is slightly incorrect from the GStreamer video converter
Jun 12, 2024
bugSomething isn't workingencodingAudio or video encoders but not the OS interfacesfundingRequires funding to implementhelp wantedExternal contribution is requiredinterfaceOS input, display, or audio interfacesupstreamRequires upstream development from dependencies
Relevant (more information about the issue):
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6902
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1260
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1315
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1339
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2948
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2991
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3495
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3556
There is an incorrect color issue (reproduced in the above issues) where it is concentrated on the video converter.
Other than the video converter, color is consistent between the source (videotestsrc or ximagesrc so no issue here), the encoder (consistent color when the same video converter is used), and output (file and WebRTC video are also consistent color).
cudaconvert
andvideoconvert
are similarly wrong for the colors, but show slightly different ways of being wrong.Therefore, this is an upstream color converter issue that needs to be fixed in GStreamer.
I think the direct cause is https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3495.
If this is not fixed, users will have a noticeable feeling of degradation of the remote screen's color reproduction.
At least in flat, single-color, static regions, the reproduction should not deviate outside +/- 1 for each RGB color and converge to the exact color when some time passes in a static state. Thus, luma should be independent of chroma changes.
The text was updated successfully, but these errors were encountered: