After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 787582 - videotestsrc: -I and +Q regions are wrong
videotestsrc: -I and +Q regions are wrong
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-09-12 11:51 UTC by Julien Isorce
Modified: 2018-11-03 11:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Julien Isorce 2017-09-12 11:51:58 UTC
The pipeline gst-launch-1.0 videotestsrc ! ximagesink videotestsrc ! xvimagesink 
does not output the same colors for some of the bottom left regions:  Blue vs Purple. To be more precise the -I (in-phase) and +Q (quadrature) regions are wrong.

Same with:

gst-launch-1.0 videotestsrc ! "video/x-raw, format=BGRx" ! ximagesink videotestsrc ! "video/x-raw, format=NV12" ! videoconvert ! ximagesink

The issue comes from https://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst/videotestsrc/videotestsrc.c#n71 , the coeffs for yuv and rgb do not match for -I and +Q. I.e. on the +Q, YCbCr(16, 235, 198) is dark purple but RGB(0, 128, 255) is blue.

With git blame I found that -I and +Q regions in videotestsrc have been introduced by commit 768253dc (year 2002). The values for yuv and rgb mentioned above are like this since that commit.

Then the -I and +Q coeffs for bt601 have been copied from bt709 in commit b97e582c (year 2008).

According to http://avisynth.nl/index.php/ColorBars_theory, this should be:

--- a/gst/videotestsrc/videotestsrc.c
+++ b/gst/videotestsrc/videotestsrc.c
@@ -67,8 +67,8 @@ static const struct vts_color_struct vts_colors_bt709_ycbcr_100[] = {
   {63, 102, 240, 255, 255, 0, 0, (64 << 8)},
   {32, 240, 118, 255, 0, 0, 255, (32 << 8)},
   {16, 128, 128, 255, 0, 0, 0, (16 << 8)},
-  {16, 198, 21, 255, 0, 0, 128, (16 << 8)},     /* -I ? */
-  {16, 235, 198, 255, 0, 128, 255, (16 << 8)},  /* +Q ? */
+  {16, 157, 99, 255, 0, 54, 98, (16 << 8)},     /* -I ? */
+  {16, 172, 146, 255, 75, 17, 126, (16 << 8)},  /* +Q ? */
   {0, 128, 128, 255, 0, 0, 0, 0},
   {32, 128, 128, 255, 19, 19, 19, (32 << 8)},
 };
@@ -97,8 +97,8 @@ static const struct vts_color_struct vts_colors_bt601_ycbcr_100[] = {
   {81, 90, 240, 255, 255, 0, 0, (64 << 8)},
   {41, 240, 110, 255, 0, 0, 255, (32 << 8)},
   {16, 128, 128, 255, 0, 0, 0, (16 << 8)},
-  {16, 198, 21, 255, 0, 0, 128, (16 << 8)},     /* -I ? */
-  {16, 235, 198, 255, 0, 128, 255, (16 << 8)},  /* +Q ? */
+  {16, 158, 95, 255, 0, 58, 98, (16 << 8)},     /* -I ? */
+  {16, 175, 148, 255, 75, 15, 126, (16 << 8)},  /* +Q ? */
   {-0, 128, 128, 255, 0, 0, 0, 0},
   {32, 128, 128, 255, 19, 19, 19, (32 << 8)},
 };

but this does not make yuv and rgb outputs to look the same either.
Comment 1 Tim-Philipp Müller 2017-09-12 16:09:33 UTC
Wim claims in bug #681308 that they're not supposed to look the same :)
Comment 2 Julien Isorce 2017-09-14 09:11:31 UTC
(In reply to Tim-Philipp Müller from comment #1)
> Wim claims in bug #681308 that they're not supposed to look the same :)

Thx for pointing that :) That would make sense but in order to understand I would like to hear how the values have been computed/selected for RGB colorspace. For instance in gstvideotestsrc these values are:

I_RGB(0,0,128)
Q_RGB(0,128,255)

Just as an example if I change Q_RGB to (128,0,255) then the +Q region becomes purple instead of blue (https://bug681308.bugzilla-attachments.gnome.org/attachment.cgi?id=220519) which would better match with the YUV image.

I tried to see how other libs do; In ffmpeg they also have a smptebars source but it only produces YUV: https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vsrc_testsrc.c#L1293
Comment 3 David Schleef 2017-09-16 00:47:44 UTC
Julien woke me up from retirement to comment on this bug.

The original RGB numbers (which are still used) were probably made up from some quick calculations by me when originally writing it, and I certainly did not care about accuracy at that time.  Years later, it kind of solidified into part of the ABI, as people (like me!) started using the output of videotestsrc as a repeatable pattern for tests.

Note that pattern=smpte was never meant to *be* the SMPTE pattern, but just be *similar to* the NTSC SD SMPTE pattern.  Note that the color bars are 100% and that there's a snow field.  I think the super-black -7.5 and sub-black +7.5 areas are slightly incorrect as well, since -7.5 corresponds to Y=-4 (I think?) and cannot be described in YCbCr space.  Also something about -I and +Q should be at 50% chroma.

I also occasionally used the difference between RGB and YUV patterns to notice when a pipeline had been negotiated differently.

Minor trivia: One of the -I or +Q is so far out of range that naive colorspace converters will calculate and clamp it incorrectly, making it bright orange.

I actually rewrote the smpte pattern in the pre-1.0 timeframe to conform to the SMPTE HD pattern specification, which happens to be well-specified for digital.  I managed to lose the patch, so it never got in.
Comment 4 Julien Isorce 2017-09-22 09:35:51 UTC
Thx a lot David for the details.

Oe could try to rework -I and +Q for both RGB and YUV spaces. And for the long run, maybe better to implement SMPTE HD and set it the default pattern in gstvideotestsrc. (Too bad that David lost it)

But all of that is already implemented in ffmeg, so another approach is to wrap the multiple video test sources in libavfilter: 
(for a preview run: ffmpeg -f lavfi -i smptehdbars=duration=10 smptehdbars.mp4 , there is also smptebars, rgbtestsrc, yuvtestsrc, allrgb, allyuv).
Comment 5 GStreamer system administrator 2018-11-03 11:59:37 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/380.