GNOME Bugzilla – Bug 787973
playbin: read the initial state of internal color balance interface
Last modified: 2018-11-03 11:59:51 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"
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"
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.
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.
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.
(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
Said that, I'm not implying that we couldn't do it better.
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.
(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.
(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.
Any update on this issue?
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.
-- 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.