Generate type=codec metadata for gstreamer packages #45
Conversation
Backends can supply information indicating that a particular package contains GStreamer decoders, encoders, etc. These are then used to create type=codec AppStream data. Implemented for Debian currently.
|
|
||
| cpt.setId (pkg.name); | ||
| cpt.setKind (ComponentKind.CODEC); | ||
| cpt.setName ("GStreamer Multimedia Codecs", "C"); |
There was a problem hiding this comment.
Not translated - not specific to the package in use. I don't know how to get anything better for here.
|
It looks like this (with master), which is a bit better.
|
|
What if I add a feature flag default false and just push this? |
|
You know I don't like this ;-) Ideally we should add metainfo files to GStreamer itself. But as a temporary workaround this is good to go I think. Can you make a feature flag for it, so people can opt-out of it if wanted? (I think it would be okay to enable this by default). Another thing: As soon as we have a better solution for GStreamer codecs, I'll remove this code again from master (with a little bit of delay so we don't break things). And sorry for the delayed reply, I have been pretty occupied with stuff and forgot that I didn't reply to the PR yet... :P |
|
I know, but I want to make this story work before switching to PK inside GS and this seems the pragmatic way to go for now. I think/hope that as I wrote it if there's a metainfo file in the package then that will win over this code anyway. Maybe we can grab GStreamer guys at GUADEC and talk about them shipping metainfo files, once we fix the spec? Or have a BOF? |
Absolutely! :) I am really usure though what the contents of the provides -> codec tag should be though... Probably allowing implementation-specific values is fine, so VLC, FFmpeg and Xine can do their own thing (since apps will probably only search by component-ID anyway since the support only one decoder implementation. Unless of course, and abstraction layer is used.) In any case, having this patch temporarily is fine. |
OK, here we go.
See https://bugzilla.gnome.org/show_bug.cgi?id=782795
The GStreamer codec listings in GS look quite bad currently, because there's no AS metadata for them. Upstream didn't want to consider this yet (AFAIK).
type=codecisn't specced properly in AS and we'd want to fix that before proposing anything up there. Fedora ships downstream metadata in their packages. For us in Debian and Ubuntu we have the ability to generate this information because our package indices specify what's in them (Gstreamer-*).I'll add some questions inline, but I hope the general idea is OK. To test: remove all the
gstreamer1.0-plugins-*andgstreamer1.0-libavpackages from your system, open an audio file in totem, launch GS when you're prompted to, and look at the list of packages offered up for installation. With this commit, you should get descriptions at least - and GS 3.26 should add icons to these too.