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 660760 - .prs presets needs to have a per-application option
.prs presets needs to have a per-application option
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: 0.10.36
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-10-03 08:11 UTC by Christian Fredrik Kalager Schaller
Modified: 2011-12-09 15:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Example prs file (667 bytes, text/plain)
2011-10-03 19:10 UTC, Christian Fredrik Kalager Schaller
  Details
add app_dir preset api (11.25 KB, patch)
2011-12-07 15:47 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
none Details | Review
add app_dir preset api (11.87 KB, patch)
2011-12-07 18:03 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
committed Details | Review
add python bindings (786 bytes, patch)
2011-12-09 13:14 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
committed Details | Review

Description Christian Fredrik Kalager Schaller 2011-10-03 08:11:49 UTC
With the introduction of encodebin the .prs presets have become a lot more prominent. One thing I realized while working on Transmageddon is that it isn't really very useful to have system wide presets, at least not for most of what you want to use presets for with encodebin. For instance if I need a preset to set a specific bitrate on an encoder, adding that as a gstreamer install wide preset is just messy. And trying to namespace presets would just create a very long preset list and also make adding presets a chore for application developers.

Instead I suggest an API addition where you can point to an application specific directory for storing your .prs files, and that the files in this directory takes precedence of any system ones.That way every application can create whatever .prs files they find useful.
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2011-10-03 18:42:03 UTC
The default implementation in the preset interface already overlays the presets in the system wide installation with those in the users home dir (under .gstreamer-0.10/presets or .config/gstreamer-0.11/presets). Presets in the homedir will shadow system wide presets. This allows to ship defaults and lets users to modify and save them.

If applications start to have special needs, we would need something like either:
gst_preset_set_domain(GstPreset *, gchar *domain);
this would need to be the first call on the iface and it would need to be repeated for each element.
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2011-10-03 18:45:07 UTC
Sent too quickly. The problem with adding new API here is that this would be specific to the default implementations. E.g. in buzztard I have elements uniquely implementing the preset interface (not using the default implementation) and for those this API addition would not make any sense.
Comment 3 Christian Fredrik Kalager Schaller 2011-10-03 19:10:51 UTC
Created attachment 198142 [details]
Example prs file

Attached example file. Originally I tried to add presets that where generic, like Quality low, normal, high, but due to requirements of specific devices I will need to add device specific entries like the example one added for PSP. Of course, the question is if there even might be an argument for quality level profiles per devices. Which would quickly populate the prs file.

Also as pointed out on IRC, since using a prs file is an integral part of the encodebin API (for setting anything not in caps, but which is properties) app developers will need to be able to create prs entries, and if they have to get these entries merged upstream, we are making things hard for people.
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2011-10-03 19:50:51 UTC
Instead of the
gst_preset_set_domain(GstPreset *, gchar *domain);
it could also be a
gst_preset_set_search_path(GstPreset *, gchar *path);
or
gst_preset_set_app_dir(GstPreset *, gchar *dir);

The def. impl. would read the presets from system, app-path/dir and then user-dir to create merged list.

I am thinking that gst_preset_set_app_dir() would be sufficient. The new API would come with an warning, to indication that not all preset implementations will handle it.
Comment 5 Luis de Bethencourt 2011-10-04 11:06:26 UTC
If we are going to follow the per-application presets route. We need to expand the tags of the presets to include where they come from.

The usecase I have in mind is when an application wants to browse just its own presets. Instead of all applications showing the exponentially growing list of all of them.
Comment 6 Christian Fredrik Kalager Schaller 2011-10-18 13:33:36 UTC
luis: while I am not against namespacing I don't think the list would be exponential as no application would see the presets of another application, they would only see their own, the user specific ones and the system one.
Comment 7 Luis de Bethencourt 2011-10-18 13:54:28 UTC
For each application to only see its own presets and the system wide ones, a "look for presets here" call needs to be added. So each application can store its presets in /usr/share or wherever and have GStreamer add those to the list.

This promotes duplication, but if we are diligent in finding any of this duplication and moving common presets into the system wide list, making this wide list a lowest common denominator, it would be good. The best solution of all the ones I've pondered.

My +1
Comment 8 Olivier Crête 2011-10-18 22:14:30 UTC
We may want "role" presets (like an encoder preset for VoIP being different than a preset for streaming or a preset for recording). Also, applications should be able to mark their presets to not be visible in other apps. Currently, I've completely duplicated the presets system inside Farstream http://www.freedesktop.org/software/farstream/apidoc/farsight2/FsElementAddedNotifier.html .. In particular see the keyfile bit.. Actually, inside farstream, I may have more than one role (if the other side supports keyframe requests or not for example). That said, maybe presets are only for user visible stuff and are not appropriate for what I do.
Comment 9 Stefan Sauer (gstreamer, gtkdoc dev) 2011-11-01 17:28:02 UTC
I see two options:

a) the application wants to have a bunch of extra presets. the application would install them to $prefix/share/<appname>/presets instead of $prefix/share/gstreamer-0.XX/presets. Presets users edit are always in the preset dir in $HOME. The gstreamer preset system would read system-dir / app-dir / user-dir and shadow presets in layers below.

For this we just need an extra function to set the appdir or even just check the application-name. The advantage here is that submitting presets to gstreamer will move them from app-dir to system-dir and thus provides an easy migration path (we might want a function that removed presets from upper layers if they have been merge to lower layers).

b) the application wants to have own presets in a completely separate namespace. This way app A won't see app Bs' presets. 

For this cloning the preset system might be the way to go.
Comment 10 Christian Fredrik Kalager Schaller 2011-12-02 11:17:40 UTC
API suggestion: 

To me this should simply be a API where you set the application prs path path

so from python I would do :
"gst.ApplicationPresetDiretory=file://usr/share/transmageddon/prs/"
Comment 11 Stefan Sauer (gstreamer, gtkdoc dev) 2011-12-07 15:47:03 UTC
Created attachment 203007 [details] [review]
add app_dir preset api

This should do the trick. Please try it and comment on the API. Will do a bit more testing in the meantime.
Comment 12 Tim-Philipp Müller 2011-12-07 16:13:52 UTC
API looks fine to me, though I would prefer _{set,get}_application_directory() instead of _app_dir().

Is there a technical reasons why we don't allow changing an already-set directory? (Other than that it's hard to come up with a use case where that's needed)
Comment 13 Tim-Philipp Müller 2011-12-07 16:14:40 UTC
Oh, and the docs could be clearer about what takes precedence - I presume the application directory?
Comment 14 Stefan Sauer (gstreamer, gtkdoc dev) 2011-12-07 17:57:19 UTC
(In reply to comment #12)
> API looks fine to me, though I would prefer _{set,get}_application_directory()
> instead of _app_dir().
> 

app was choosen due to app src/sink
dir was chose as glib uses dir instead of directory

> Is there a technical reasons why we don't allow changing an already-set
> directory? (Other than that it's hard to come up with a use case where that's
> needed)

One the path has been determined it is stored in qdata of the element-type. Invalidating the path' would be difficult. Also computing them every time would be fine, but then we would leak them (the current API returns read-only references for the other two path). 

> Oh, and the docs could be clearer about what takes precedence - I presume the
> application directory?

Will explain better. It is system < app < user. Rational is that most likely the user folder is the only writable one.
Comment 15 Stefan Sauer (gstreamer, gtkdoc dev) 2011-12-07 18:03:00 UTC
Created attachment 203024 [details] [review]
add app_dir preset api

more docs.
Comment 16 Stefan Sauer (gstreamer, gtkdoc dev) 2011-12-09 13:14:55 UTC
Created attachment 203146 [details] [review]
add python bindings

> python
>>> import gst;
>>> gst.preset_set_app_dir("/home/ensonic")
True
>>> gst.preset_get_app_dir()
'/home/ensonic'
>>>
Comment 17 Christian Fredrik Kalager Schaller 2011-12-09 13:19:49 UTC
I think the better naming of this API would be gst.Preset.get_app_dir, would fit in with the other Preset related API calls then
Comment 18 Christian Fredrik Kalager Schaller 2011-12-09 13:31:06 UTC
Another python API question (maybe also cover C Api), should it be in uri format?
Comment 19 Stefan Sauer (gstreamer, gtkdoc dev) 2011-12-09 13:32:30 UTC
(In reply to comment #18)
> Another python API question (maybe also cover C Api), should it be in uri
> format?

no, those are local directories.
Comment 20 Christian Fredrik Kalager Schaller 2011-12-09 14:14:11 UTC
Ok, git master of transmageddon now use this new API, tested and working.