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 708889 - Add "smart-properties" property in playbin
Add "smart-properties" property in playbin
Status: RESOLVED DUPLICATE of bug 578933
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-09-27 05:49 UTC by HoonHee Lee
Modified: 2013-09-27 08:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
this is a patch file. (6.52 KB, patch)
2013-09-27 06:34 UTC, HoonHee Lee
none Details | Review

Description HoonHee Lee 2013-09-27 05:49:06 UTC
Overview:
I just wanted to set some properties to demuxer or parser or other elements in uridecodebin before PAUSE state.
For this, I had to find a element that I wanted to set one by one and I could set a value of property using bus message.

So, I Added "smart-properties" property in playbin.
This property makes to be possible that all of elements in uridecodebin
can set directly their's properties while auto-plugging.
A property should be comprised of key and value and split by ':' delimiter.
All of properties should be split by ',' delimiter.

Expected Results:
1. gst-launch1.0 playbin uri="xxx" smart-properties="program-number:3,emit-stats:TRUE"
2. It is stored to hash table after parsing.
3. While auto-plugging, if there is a matched name of property in a element that is from uridecodebin with hash table, the element starts to set a value of property.
Comment 1 HoonHee Lee 2013-09-27 06:34:13 UTC
Created attachment 255896 [details] [review]
this is a patch file.
Comment 2 Tim-Philipp Müller 2013-09-27 08:24:10 UTC
Thanks for the patch.

I think this is a duplicate of bug #578933 for all practical purposes, even if the proposed solution is a bit different.

I don't think a property like this is a good idea, it has lots of problems, such as not being able to restrict which elements to apply it to, properties with the same name but different types on different elements, things like that. Also, the GstChildProxy interface would probably be a better fit for this in general.

Lastly, even if a property-based approach was suitable here, the name is not ideal IMHO ("smart" doesn't really mean anything, it doesn't tell anyone anything in addition to -properties) (but that's not so important, just mentioning it while we're at it :))

*** This bug has been marked as a duplicate of bug 578933 ***