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 787973 - playbin: read the initial state of internal color balance interface
playbin: read the initial state of internal color balance interface
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.12.3
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-09-21 07:39 UTC by Ung, Teng En
Modified: 2018-11-03 11:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ung, Teng En 2017-09-21 07:39:56 UTC
In linux with gstreamer 1.8.3, when try using playbin and assign the color balance with video-sink.  The value got reset to other value.

Run the test with gstreamer vaapi, when we don't use playbin the color balance value will apply :-
    gst-launch-1.0 filesrc location=<Video> ! qtdemux ! queue ! h264parse ! vaapidecode ! queue ! vaapisink hue=180


But when use playbin and change the video-sink to include color balance value; it will be reset to default :-
    gst-launch-1.0 playbin2 uri=<Video> video-sink="vaapisink hue=180"
Comment 1 Ung, Teng En 2017-09-26 02:24:22 UTC
I retested this issue on gstreamer and gstreamer-vaapi both in 1.12.3, and it is still reproducible.

The normal vaapi command :-
    gst-launch-1.0 filesrc location=<Video> ! qtdemux ! queue ! h264parse ! vaapih264dec ! queue ! vaapisink hue=180

The playbin command are :-
    gst-launch-1.0 playbin uri=<Video> video-sink="vaapisink hue=180"
Comment 2 Hyunjun Ko 2017-09-26 08:27:00 UTC
This is caused by update from playsink through gst_vaapisink_color_balance_set_value if using gst-play.

I think we should handle this case with prior to user-input.
Comment 3 Víctor Manuel Jáquez Leal 2017-09-26 09:23:04 UTC
In my opinion, the color balance interface should have more priority than the user parameter. Thus, this is the correct behavior, since playbin proxies the color balance interface. Following this logic, your application could control the color balance (hue) regardless the used video sink.
Comment 4 Ung, Teng En 2017-09-27 02:52:52 UTC
Well, the other parameter passed in like " fullscreen=true " have same effect on both cases.  Thus, from user point of view, it seems like the behavior on the color balance have different behavior with look like a bug.  Is there anyway that user can initialize the color balance value on the beginning through playbin.
Comment 5 Víctor Manuel Jáquez Leal 2017-09-29 09:21:20 UTC
(In reply to Ung, Teng En from comment #4)
> Well, the other parameter passed in like " fullscreen=true " have same
> effect on both cases.  

As far as I understand, that a different situation, since I'm not aware of a fullscreen interface, neither one similar proxied by playbin. 

Also, normally fullscreen mode is handled by the application, but in the specific case of vaapisink, there's a property just for testing purposes.

> Thus, from user point of view, it seems like the
> behavior on the color balance have different behavior with look like a bug. 

IMO this is conclusion couldn't be valid.

> Is there anyway that user can initialize the color balance value on the
> beginning through playbin.

By using a gst-launch-1.0 or gst-play-1.0 it seems not. But by an application, you should, by getting the color balance interface from the playbin and setting the hue, for example.

https://gstreamer.freedesktop.org/documentation/tutorials/playback/color-balance.html#color-balance-example
Comment 6 Víctor Manuel Jáquez Leal 2017-09-29 09:23:31 UTC
Said that, I'm not implying that we couldn't do it better.
Comment 7 Ung, Teng En 2017-10-04 03:19:19 UTC
By going through the playbin source.  It seems it keep its own color balance proxies and have their own range.  And their range are different to other elements.  

Can those proxies be removes from playbin and it just pass through all these handling of color balance to underneath elements, since it don't have any real control of those.  This may make the whole user experience more aligned.

Anyway, if playbin want to keep its own proxies, probably it could add the color balance element properties, so the user can initialized the value and know what is the range of the color balances for playbin.
Comment 8 Víctor Manuel Jáquez Leal 2017-10-04 05:25:46 UTC
(In reply to Ung, Teng En from comment #7)

> Can those proxies be removes from playbin and it just pass through all these
> handling of color balance to underneath elements, since it don't have any
> real control of those.  This may make the whole user experience more aligned.

I don't think it would be possible to remove the interfaces from playbin, a ton of applications in the world will break.

As far as I know, only vaapisink exposes as property the color balance controls, no other sink does it, they expose them through the interface. So perhaps it was a design error, but we have keep them now.

The only solution it came to my mind is to make the proxy in playbin to read the current values of the proxied element at the beginning.
Comment 9 Ung, Teng En 2017-10-04 07:38:11 UTC
(In reply to Víctor Manuel Jáquez Leal from comment #8)
> The only solution it came to my mind is to make the proxy in playbin to read
> the current values of the proxied element at the beginning.

Syncing the value of color balances in playbin with the proxied elements instead of changing them definitely help.

Thanks.
Comment 10 Ung, Teng En 2017-11-30 02:23:44 UTC
Any update on this issue?
Comment 11 Nicolas Dufresne (ndufresne) 2017-12-06 19:30:47 UTC
So did we agree that playbin, as a proxy, should read back the values when elements implementing the interface get added/initialized ? If so, don't forget to notify it though g_object_notify. I think it's pending someone to write a patch.
Comment 12 GStreamer system administrator 2018-11-03 11:59:51 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/382.