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 701202 - playsink: Badly initialized contrast/brightness
playsink: Badly initialized contrast/brightness
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.0.7
Other Linux
: Normal normal
: 1.1.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-05-29 16:00 UTC by Daniel Drake
Modified: 2013-05-29 18:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (1.85 KB, patch)
2013-05-29 16:49 UTC, Daniel Drake
committed Details | Review

Description Daniel Drake 2013-05-29 16:00:23 UTC
I am playing back a Theora video via xvimagesink with:
   gst-launch-1.0 playbin uri=file:///home/olpc/test.ogg

And it appears all-black on OLPC XO-1.5. This is a regression over gstreamer-0.10. Here's what happens:

The underlying X11 graphics driver offers the XV_BRIGHTNESS attribute with range 0 to 10000, default value 5000 (normal brightness). At the extremes, value 0 is totally black (dark), value 10000 is totally white (bright). This range and default value gets correctly communicated from the X server into the color balance channel created by xvimagesink.

When the video is about to be played, in gstplaysink.c gen_video_chain() gets called. This finds the colorbalance element of the xvimagesink and then calls update_colorbalance().

update_colorbalance goes through all the channels, including brightness, and sends values down to xvimagesink by calling gst_color_balance_set_value().

Which values does it use at this point? Well, values have not been set by any user, so we are sending down the ones set in gst_play_sink_init():

  channel->label = g_strdup ("BRIGHTNESS");
  channel->min_value = -1000;
  channel->max_value = 1000;
  playsink->colorbalance_channels =
      g_list_append (playsink->colorbalance_channels, channel);
  playsink->colorbalance_values[1] = 0;

and we send that value *without any normalization* to what the proxy might accept.

So xvimagesink receives a request to set brightness=0 (where the valid values are from 0(dark) to 10000(bright)) which means "all black" and then it goes ahead and plays back the video all black. :(
Comment 1 Daniel Drake 2013-05-29 16:49:23 UTC
Created attachment 245565 [details] [review]
patch
Comment 2 Sebastian Dröge (slomo) 2013-05-29 18:22:22 UTC
commit d32d2f0b141155209b8c64a7b293f1bf89041073
Author: Daniel Drake <dsd@laptop.org>
Date:   Wed May 29 10:33:48 2013 -0600

    playsink: pass translated color balance value to channel
    
    We found a case where untranslated values were being passed from the
    proxy to the underlying channel, causing bad color balance values
    in some setups.
    
    Thanks to Sebastian Dröge for clarifying how the code works, and
    suggesting the fix.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=701202