OBS seemingly ignoring proper color range mapping for gstreamer source about obs-gstreamer HOT 6 CLOSED

So the main question is where in the process the error occurs.

From this plugins point of view it would be interesting to see if this piece of code results in the expecting:

	enum video_range_type range = VIDEO_RANGE_DEFAULT;
	switch (video_info.colorimetry.range) {
	case GST_VIDEO_COLOR_RANGE_0_255:
		range = VIDEO_RANGE_FULL;
		frame.full_range = 1;
		break;
	case GST_VIDEO_COLOR_RANGE_16_235:
		range = VIDEO_RANGE_PARTIAL;
		break;
	default:
		break;
	}

	enum video_colorspace cs = VIDEO_CS_DEFAULT;
	switch (video_info.colorimetry.matrix) {
	case GST_VIDEO_COLOR_MATRIX_BT709:
		cs = VIDEO_CS_709;
		break;
	case GST_VIDEO_COLOR_MATRIX_BT601:
		cs = VIDEO_CS_601;
		break;
	default:
		break;
	}

If that seems fine one would have to look at the OBS side of things as there is nothing more than this plugin can do.

It could be that this information is incorrectly handled in the GStreamer pipeline itself, which could be a problem in GStreamer itself.

Then again we know nothing about the codecs used and decoded in your pipeline. RTSP cameas often send MPEG streams, which are in YUV after decoding and usually partial range.

I can get around this bug by converting the format first to YUY2 and then to raw

YUY2 is a raw format by itself, so I'm not sure what other conversion is involved. It may be OBS doesn't support YUY2 and it gets converted to another format. It is already raw though nonetheless.

from obs-gstreamer.

I should have specified in my first post that this is my first time using gstreamer so there may be things I have overlooked. Nonetheless, I have read through much of the documentation and think I am coming to an understanding of how the pipelines work. How would I go about looking at the output result of my pipeline like you mentioned? As for the codec sent by the camera, this is all the information given by gst-dsicoverer.

gst-discoverer-1.0 rtsp://10.0.0.57:554/1 -v
Analyzing rtsp://10.0.0.57:554/1
Done discovering rtsp://10.0.0.57:554/1

Topology:
unknown: application/x-rtp, media=(string)video, payload=(int)96, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)64002A, sprop-parameter-sets=(string)"Z2QAKq2EAQwgCGEAQwgCGEAQwgCEO1A8ARPyzcBAQECA,aO48sA==", a-framesize=(string)1920-1080, ssrc=(uint)1859099176, npt-start=(guint64)0, play-speed=(double)1, play-scale=(double)1
video: video/x-h264, stream-format=(string)avc, alignment=(string)au, codec_data=(buffer)0164002affe100216764002aad84010c20086100430802184010c200843b503c0113f2cdc04040408001000468ee3cb0, level=(string)4.2, profile=(string)high, width=(int)1920, height=(int)1080, framerate=(fraction)0/1, interlace-mode=(string)progressive, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true
Tags:
video codec: H.264 (High Profile)

  Codec:
    video/x-h264, stream-format=(string)avc, alignment=(string)au, codec_data=(buffer)0164002affe100216764002aad84010c20086100430802184010c200843b503c0113f2cdc04040408001000468ee3cb0, level=(string)4.2, profile=(string)high, width=(int)1920, height=(int)1080, framerate=(fraction)0/1, interlace-mode=(string)progressive, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true
  Additional info:
    None
  Stream ID: 9fc1cc3b5a52cbe6c31a1d563dd2e833c9cd3944d4b94a17629652ed8f821c61/video:0:0:RTP:AVP:96
  Width: 1920
  Height: 1080
  Depth: 24
  Frame rate: 0/1
  Pixel aspect ratio: 1/1
  Interlaced: false
  Bitrate: 0
  Max bitrate: 0

Properties:
Duration: 99:99:99.999999999
Seekable: no
Live: yes
Tags:
video codec: H.264 (High Profile)

from obs-gstreamer.

should have specified in my first post that this is my first time using gstreamer

Fair enough :-)

The TL;DR would be: This plugin is rather "dumb". It passes data it gets from GStreamer along to OBS. It doesn't really do anything with this data other than trying to match the formats between these two and passes available information on. In other words, as long as this a->b passing works, it works as expected. If all information is passed, OBS "should do it's thing" ™.

Coming to that color space. Rule of thumb often is:

• YUV data is narrow range
• RGB data is full range

However this is not set in stone. H.264 video for example has an optional flag where the range can be set. A decoder should pass on the flag (and others) or the resulting data can not be correctly interpreted. It is definitely YUV data though.

As long as you stay in YUV space from here things are probably ok. As long you still know if the original data is full or narrow range. When you convert to RGB (which at some point probably has to be done in OBS) it is important to select the right conversion method - depending on source and target ranges.

To verify a correct conversion routine you would have to check upon all involved components and check they are doing the right thing. That's basically opening Pandora's box.

Don't get we wrong - it may still be possible it is a bug in GStreamer, OBS or this plugin. But just because your expectation is a different one does not mean it is doing the wrong thing technically. Just because you expect black to be 0 doesn't mean it has to be.

So - as long you don't research what ranges and color primaries every component operates on and why it cannot be said whether the behavior is correct or incorrect.

from obs-gstreamer.

Understood. On an unrelated note, but since you have been kind enough to respond in great detail so far. When I use the pipeline time stamps checkbox within obs, a delay of about 130ms is introduced as opposed to without it. I am unable to record through obs without it checked as no matter what I do I get duplicate and dropped frames in the resulting recording. I've tried implementing something like this (rtspsrc location=rtsp://10.0.0.57:554/1 buffer-mode=0 latency=100 ! rtpjitterbuffer mode=0 ! decodebin ! videoconvert ! video/x-raw,format=YUY2 ! video.) but that doesn't seem to make any difference. Any suggestions? I've tried changed the buffer modes, adjusting the latency property, etc

from obs-gstreamer.

Enabling timestamps will introduce some latency. Due to the nature of network links and codec buffer models that is most likely inevitable.

Without time stamps frames get displayed as soon as they are received and decoded. That's as quickly displayed as possible but that means the time between each frames varies extremely. That may cause effects like seing duplicated frames and some skipping.

Timestamps enabled will throttle the display times to show them accordingly to create a smooth stream. But you require some head room (latency) to schedule them correctly and to not to under-run your buffer and make the stream look jerky.

I believe GStreamer tries to find the sweet spot. I wouldn't try to mess with it without a good reason and some knowledge.

Multimedia streaming is hard :-)

from obs-gstreamer.

P.S. When I wrote the above i was thinking about "sync appsink to clock". Timestamps in OBS are somewhat not documented - and have weird behavior in my experience. That options exists just change behavior.. in case one option works better for you than the other.. not great.. not terrible..

from obs-gstreamer.