Hey,
I wanted to gauge interest for this particular solution to a long-standing problem, that of being able to play back videos in the user's possession.
TL;DR: Remove totem so that users get it from a place where it can play videos
A long, long time ago, thomasvs and I worked on implementing a mechanism for automatic codec installation in GStreamer applications, such as totem: https://fedoraproject.org/wiki/Releases/FeatureCodecBuddy https://fedoraproject.org/wiki/Interviews/CodecBuddy https://arstechnica.com/information-technology/2007/09/gnome-2-20-officially...
There was only one implementation, which offered a native(-ish) front-end to Fluendo's web store. Fluendo at that time was[1] providing proprietary plugins so that distributions based in jurisdictions where software patents applied, or that wanted to distribute there, or organisations where this applied, could buy those plugins to get peace of mind.
Obviously, pointing to a company's webstore in a package that was part of Fedora's default installation didn't go down well, and the implementation was replaced with something more generic: GStreamer plugins inside packages would be scanned at build time to have "RPM provides" metadata added to the package, and an application[2] was added to look for "a package that provides this thing" when a multimedia application was missing a plugin.
Fast-forward 12 years, and even if the name of the codecs that are missing have changed, and what we can automatically install online to has also changed (we have full MP3 support, yay! but the AAC and H264 support are rather incomplete), the workflow is still the same, but probably slightly more broken.
The problems: - the PackageKit GStreamer plugin installer doesn't implement the "missing- plugins" interface correctly: https://bugs.freedesktop.org/show_bug.cgi?id=100791 which breaks applications (because it tells the app to re-scan the installed plugins even though nothing's installed yet): https://gitlab.gnome.org/GNOME/totem/issues/62
- The "provides" in the RPM packages can't fully express the required plugins. The GStreamer missing plugins code gives out a very very detailed information on what plugin is needed, something which cannot be implemented via the simple string comparison we use to select which package to install. This is a problem you could get with the plugins that Fedora points to out of the box, but that don't implement all the profiles[3].
- Even if a compatible plugin gets installed, it might not be _the_ plugin that needs to be used to integrate a particular feature. For example, the GStreamer DVD playback plugin requires the liba52-based AC3 decoder to work, and will not work with another one.[4]
- The user still needs to figure out where to get the rest of the codecs. Want to play H265? Go search for the repository that provides this. Want to play DVDs? It won't install automatically and you'll also need to search for it.
- Providing the automatic codecs installation functionality using the RPM-based Flatpaks for Silverblue would be a *lot* of infrastructure work, if it even is feasible[5].
If for some reason we decide that we want to keep totem in the distribution, then a number of things would need to happen: - PackageKit's plugin installation helper would need to be fixed to match what the API requires - We'd need to review popular codecs, and make sure that for both decoders and encoders, enough metadata is available in the RPM provides for the "right" ones to be installed - Figure out what to do for the RPM-based Flatpaks
Note that this only applies to Fedora. If somebody wants to discuss the status of this for the other distribution on which I work, please reply privately.
Cheers
[1]: Maybe they still are? The page still mentioned GStreamer 0.10: https://fluendo.com/en/products/enterprise/fluendo-codec-pack/ [2]: Might have been a PackageKit front-end already, I couldn't find a reference after a quick web search, and it's not super relevant [3]: I've not verified/tested this, I know it to be a possibility though [4]: This isn't a problem since Fedora ships the a52dec, but it was one [5]: It's always feasible, given enough time ;)
On Tue, Feb 19, 2019 at 2:22 PM Bastien Nocera bnocera@redhat.com wrote:
Hey,
I wanted to gauge interest for this particular solution to a long-standing problem, that of being able to play back videos in the user's possession.
TL;DR: Remove totem so that users get it from a place where it can play videos
A long, long time ago, thomasvs and I worked on implementing a mechanism for automatic codec installation in GStreamer applications, such as totem: https://fedoraproject.org/wiki/Releases/FeatureCodecBuddy https://fedoraproject.org/wiki/Interviews/CodecBuddy https://arstechnica.com/information-technology/2007/09/gnome-2-20-officially...
There was only one implementation, which offered a native(-ish) front-end to Fluendo's web store. Fluendo at that time was[1] providing proprietary plugins so that distributions based in jurisdictions where software patents applied, or that wanted to distribute there, or organisations where this applied, could buy those plugins to get peace of mind.
Obviously, pointing to a company's webstore in a package that was part of Fedora's default installation didn't go down well, and the implementation was replaced with something more generic: GStreamer plugins inside packages would be scanned at build time to have "RPM provides" metadata added to the package, and an application[2] was added to look for "a package that provides this thing" when a multimedia application was missing a plugin.
Fast-forward 12 years, and even if the name of the codecs that are missing have changed, and what we can automatically install online to has also changed (we have full MP3 support, yay! but the AAC and H264 support are rather incomplete), the workflow is still the same, but probably slightly more broken.
The problems:
- the PackageKit GStreamer plugin installer doesn't implement the "missing-
plugins" interface correctly: https://bugs.freedesktop.org/show_bug.cgi?id=100791 which breaks applications (because it tells the app to re-scan the installed plugins even though nothing's installed yet): https://gitlab.gnome.org/GNOME/totem/issues/62
- The "provides" in the RPM packages can't fully express the required plugins. The
GStreamer missing plugins code gives out a very very detailed information on what plugin is needed, something which cannot be implemented via the simple string comparison we use to select which package to install. This is a problem you could get with the plugins that Fedora points to out of the box, but that don't implement all the profiles[3].
- Even if a compatible plugin gets installed, it might not be _the_ plugin that
needs to be used to integrate a particular feature. For example, the GStreamer DVD playback plugin requires the liba52-based AC3 decoder to work, and will not work with another one.[4]
- The user still needs to figure out where to get the rest of the codecs.
Want to play H265? Go search for the repository that provides this. Want to play DVDs? It won't install automatically and you'll also need to search for it.
- Providing the automatic codecs installation functionality using the RPM-based
Flatpaks for Silverblue would be a *lot* of infrastructure work, if it even is feasible[5].
If for some reason we decide that we want to keep totem in the distribution, then a number of things would need to happen:
- PackageKit's plugin installation helper would need to be fixed to match what the API requires
Is that worth it given it seems PackageKit is being EOLed? https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well...
- We'd need to review popular codecs, and make sure that for both decoders and encoders, enough metadata is available in the RPM provides for the "right" ones to be installed
- Figure out what to do for the RPM-based Flatpaks
Note that this only applies to Fedora. If somebody wants to discuss the status of this for the other distribution on which I work, please reply privately.
Cheers
[1]: Maybe they still are? The page still mentioned GStreamer 0.10: https://fluendo.com/en/products/enterprise/fluendo-codec-pack/ [2]: Might have been a PackageKit front-end already, I couldn't find a reference after a quick web search, and it's not super relevant [3]: I've not verified/tested this, I know it to be a possibility though [4]: This isn't a problem since Fedora ships the a52dec, but it was one [5]: It's always feasible, given enough time ;) _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
----- Original Message -----
On Tue, Feb 19, 2019 at 2:22 PM Bastien Nocera bnocera@redhat.com wrote:
If for some reason we decide that we want to keep totem in the distribution, then a number of things would need to happen:
- PackageKit's plugin installation helper would need to be fixed to match what the API requires
Is that worth it given it seems PackageKit is being EOLed? https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well...
I completely forgot to mention it, even though it was on my mind when the article was published last week.
I expect the feature to be replaced by something GNOME Software specific if we want to keep the feature alive in Fedora. I also don't think this EOL'ing is something that's going to happen in the next 3 or 4 cycles, though Richard or Kalev would obviously know more.
Personally, I don't think putting forth effort into missing codec installation makes much sense. Since this feature isn't working well, we might as well just disable it. If you have to enable rpmfusion to get the missing codec workflow to work, well, users who are smart enough to do that can just install the codecs they want anyway. It's better to ensure that we install whatever important codecs we can by default.
I think totem is still useful though. MP4 and AAC are both coming soon, right, and it's expected to be good enough to play most MP4 files, including web videos? Why do you say they are "rather incomplete"? Even without MP4, it's still helpful to be capable of playing WebM, e.g. gnome-shell screencasts.
Michael
----- Original Message -----
Personally, I don't think putting forth effort into missing codec installation makes much sense. Since this feature isn't working well, we might as well just disable it.
It's not working well, but it's still working. Even if you were to disable it for totem, all the other GStreamer apps are still potential consumers.
If you have to enable rpmfusion to get the missing codec workflow to work, well, users who are smart enough to do that can just install the codecs they want anyway.
This is exactly it. And I'd rather have them find a version that doesn't require hunting down codecs and has (most of) all the bits upfront.
It's better to ensure that we install whatever important codecs we can by default.
That's certainly a laudable goal, but until all the patents have expired, and the industry uses patent-free codecs, not an option for Fedora.
I think totem is still useful though. MP4 and AAC are both coming soon, right, and it's expected to be good enough to play most MP4 files, including web videos? Why do you say they are "rather incomplete"?
The OpenH264 plugin only supports baseline profile, from gst-inspect-1.0: Capabilities: video/x-h264 stream-format: byte-stream alignment: au profile: { (string)constrained-baseline, (string)baseline }
We would want at least High Profile: https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles
There's still no AAC GStreamer plugin shipped in Fedora, and FDK-AAC won't have HE-AAC decoding support, which isn't yet a problem, but could be soon.
Even without MP4, it's still helpful to be capable of playing WebM, e.g. gnome-shell screencasts.
An actual screencast application could do this. So could sushi (nautilus' preview app, press the space bar in your file manager). Note that if there *must* be a player for those screencasts, I'm happy to write the smallest of video players that would only support WebM.
On Tue, Feb 19, 2019 at 3:22 PM Bastien Nocera bnocera@redhat.com wrote:
Hey,
I wanted to gauge interest for this particular solution to a long-standing problem, that of being able to play back videos in the user's possession.
TL;DR: Remove totem so that users get it from a place where it can play videos
I don't understand how removing Totem from the default installation (or even completely from Fedora), without a replacement, helps end users. How is their situation supposed to get improved with this step? Power users will manage, but the group which actually liked a simple-interface video player like Totem (or perhaps used it as a default video player for their parents - my case) will need to look for a new one. General users will be clueless and will search the Internet, discovering broken outdated guides all around (of course, that's the same situation as with missing codecs. Also, we're talking just about users from countries where software patents don't apply, obviously). Additionally, if the video player is present but can't play the content, at least a reasonable message can be presented to the user, perhaps with some guidance and links (example https://fedoraproject.org/wiki/Multimedia). If the player is not installed at all, the user is left completely in the dark. Overall, by removing the video player, I don't see improvements in any of those cases, and I see more complications for some of them.
Also, having a Workstation product without a pre-installed video player is guaranteed to get bad press (and I don't mean just journalists, but user opinions). Suddenly, "Fedora" can't even play open-source codecs by default. Our mission is to "advance software and content freedom", but we wouldn't be even able to play FOSS content out-of-the-box? That's really... weird.
It seems ironic to me that such a proposal would arrive in a time when we're in the best situation ever, compared to history. Many codecs patents expired lately (mostly audio, true) and we can play them reasonably well. VP8 and VP9 are used on a massive scale (YouTube), even though in situations where common users don't interact with them (unless you download videos from YouTube, I do). WebM hasn't made the impact we wished for, but you can still see it from time to time, particularly with FOSS-related events. Hopefully AV1 will change this. Overall, it's not much, yes, but it's still better than it used to be (at least that's my perception). And I believe I saw a claim somewhere (can't remember where) that we could get higher profile support in openh264 in a near future (perhaps Christian can comment on this). That would of course flip this whole discussion upside down, because suddenly we'd be able to play the most widespread video codec.
----- Original Message -----
I don't understand how removing Totem from the default installation (or even completely from Fedora), without a replacement, helps end users. How is their situation supposed to get improved with this step? Power users will manage, but the group which actually liked a simple-interface video player like Totem (or perhaps used it as a default video player for their parents - my case) will need to look for a new one. General users will be clueless and will search the Internet, discovering broken outdated guides all around (of course, that's the same situation as with missing codecs. Also, we're talking just about users from countries where software patents don't apply, obviously). Additionally, if the video player is present but can't play the content, at least a reasonable message can be presented to the user, perhaps with some guidance and links ( example ). If the player is not installed at all, the user is left completely in the dark. Overall, by removing the video player, I don't see improvements in any of those cases, and I see more complications for some of them.
GNOME Videos will still be available, from here: https://flathub.org/apps/details/org.gnome.Totem with all the bells and whistles.
I think that, out-of-the-box, clicking on "Install" on this website will lead to a better experience than 1) finding out about third-party RPM repositories 2) enabling said repositories 3) triggering the codecs to be installed, including the aforementioned PackageKit-gstreamer helper bugs
I intend to advertise the upstream distribution of totem via my own blog, and Fedora Magazine (which apparently can link to Flathub without problems).
Also, having a Workstation product without a pre-installed video player is guaranteed to get bad press (and I don't mean just journalists, but user opinions). Suddenly, "Fedora" can't even play open-source codecs by default. Our mission is to "advance software and content freedom", but we wouldn't be even able to play FOSS content out-of-the-box? That's really... weird.
Not to find false equivalences, but we don't ship with a mail client out-of-the-box either.
I'd really rather not have the application available in Fedora, than have it be a cut-down version that's really hard to extend. In the end, the end-users will go the way you mentioned earlier, look for a video player, and end up installing VLC from Flathub, instead of trying to figure out why this sucky video player couldn't play anything.
It seems ironic to me that such a proposal would arrive in a time when we're in the best situation ever, compared to history. Many codecs patents expired lately (mostly audio, true) and we can play them reasonably well. VP8 and VP9 are used on a massive scale (YouTube), even though in situations where common users don't interact with them (unless you download videos from YouTube, I do). WebM hasn't made the impact we wished for, but you can still see it from time to time, particularly with FOSS-related events. Hopefully AV1 will change this. Overall, it's not much, yes, but it's still better than it used to be (at least that's my perception). And I believe I saw a claim somewhere (can't remember where) that we could get higher profile support in openh264 in a near future (perhaps Christian can comment on this). That would of course flip this whole discussion upside down, because suddenly we'd be able to play the most widespread video codec.
There's a long tail of codecs that are not playable on Fedora, and will probably never be playable, most of them too niche to be worth spending the time to look whether they're covered by patents that are still running, and there's some already reasonable amount of videos available online as H265, which we won't be able to support for a while.
The support is better than it's been, but it's still far from optimal, and this discussion only covers GStreamer codecs and demuxers, which can be detected and somewhat automatically installed. We also have the question of other patent-covered uses such as video acceleration.
Cheers
On 2/20/19 9:41 AM, Bastien Nocera wrote:
----- Original Message -----
I don't understand how removing Totem from the default installation (or even completely from Fedora), without a replacement, helps end users. How is their situation supposed to get improved with this step? Power users will manage, but the group which actually liked a simple-interface video player like Totem (or perhaps used it as a default video player for their parents - my case) will need to look for a new one. General users will be clueless and will search the Internet, discovering broken outdated guides all around (of course, that's the same situation as with missing codecs. Also, we're talking just about users from countries where software patents don't apply, obviously). Additionally, if the video player is present but can't play the content, at least a reasonable message can be presented to the user, perhaps with some guidance and links ( example ). If the player is not installed at all, the user is left completely in the dark. Overall, by removing the video player, I don't see improvements in any of those cases, and I see more complications for some of them.
GNOME Videos will still be available, from here: https://flathub.org/apps/details/org.gnome.Totem with all the bells and whistles.
How people will find about it? GNOME Software? if true, why it is fine to show on GNOME Software an application full of patented codecs vs showing a codec pack from rpmfusion? I mean the legal aspects of not adding rpmfusion as a repository are known, but I don't find any difference with flathub then.
I think that, out-of-the-box, clicking on "Install" on this website will lead to a better experience than 1) finding out about third-party RPM repositories 2) enabling said repositories 3) triggering the codecs to be installed, including the aforementioned PackageKit-gstreamer helper bugs
I intend to advertise the upstream distribution of totem via my own blog, and Fedora Magazine (which apparently can link to Flathub without problems).
Also, having a Workstation product without a pre-installed video player is guaranteed to get bad press (and I don't mean just journalists, but user opinions). Suddenly, "Fedora" can't even play open-source codecs by default. Our mission is to "advance software and content freedom", but we wouldn't be even able to play FOSS content out-of-the-box? That's really... weird.
Not to find false equivalences, but we don't ship with a mail client out-of-the-box either.
I'd really rather not have the application available in Fedora, than have it be a cut-down version that's really hard to extend. In the end, the end-users will go the way you mentioned earlier, look for a video player, and end up installing VLC from Flathub, instead of trying to figure out why this sucky video player couldn't play anything.
It seems ironic to me that such a proposal would arrive in a time when we're in the best situation ever, compared to history. Many codecs patents expired lately (mostly audio, true) and we can play them reasonably well. VP8 and VP9 are used on a massive scale (YouTube), even though in situations where common users don't interact with them (unless you download videos from YouTube, I do). WebM hasn't made the impact we wished for, but you can still see it from time to time, particularly with FOSS-related events. Hopefully AV1 will change this. Overall, it's not much, yes, but it's still better than it used to be (at least that's my perception). And I believe I saw a claim somewhere (can't remember where) that we could get higher profile support in openh264 in a near future (perhaps Christian can comment on this). That would of course flip this whole discussion upside down, because suddenly we'd be able to play the most widespread video codec.
There's a long tail of codecs that are not playable on Fedora, and will probably never be playable, most of them too niche to be worth spending the time to look whether they're covered by patents that are still running, and there's some already reasonable amount of videos available online as H265, which we won't be able to support for a while.
The support is better than it's been, but it's still far from optimal, and this discussion only covers GStreamer codecs and demuxers, which can be detected and somewhat automatically installed. We also have the question of other patent-covered uses such as video acceleration.
Cheers _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
Hello, many words have been written, so I will just keep it short.
My opinion is that unless there is a replacement for Videos, it should stay there, whatever problems with missing codecs it has. Removing applications because they are not perfect is not a way to go. The way to go is to make the applications perfect, so that they could stay.
I am not a Gnome Video user, I even ain't a Gnome user. but I think our users deserve a good treatment and service.
Thanks for understanding. Lukas
On Wed, Feb 20, 2019 at 2:48 PM Robert Marcano robert@marcanoonline.com wrote:
On 2/20/19 9:41 AM, Bastien Nocera wrote:
----- Original Message -----
I don't understand how removing Totem from the default installation (or
even
completely from Fedora), without a replacement, helps end users. How is their situation supposed to get improved with this step? Power users
will
manage, but the group which actually liked a simple-interface video
player
like Totem (or perhaps used it as a default video player for their
parents -
my case) will need to look for a new one. General users will be
clueless and
will search the Internet, discovering broken outdated guides all around
(of
course, that's the same situation as with missing codecs. Also, we're talking just about users from countries where software patents don't
apply,
obviously). Additionally, if the video player is present but can't play
the
content, at least a reasonable message can be presented to the user,
perhaps
with some guidance and links ( example ). If the player is not
installed at
all, the user is left completely in the dark. Overall, by removing the
video
player, I don't see improvements in any of those cases, and I see more complications for some of them.
GNOME Videos will still be available, from here: https://flathub.org/apps/details/org.gnome.Totem with all the bells and whistles.
How people will find about it? GNOME Software? if true, why it is fine to show on GNOME Software an application full of patented codecs vs showing a codec pack from rpmfusion? I mean the legal aspects of not adding rpmfusion as a repository are known, but I don't find any difference with flathub then.
I think that, out-of-the-box, clicking on "Install" on this website will
lead
to a better experience than 1) finding out about third-party RPM
repositories
- enabling said repositories 3) triggering the codecs to be installed,
including
the aforementioned PackageKit-gstreamer helper bugs
I intend to advertise the upstream distribution of totem via my own
blog, and
Fedora Magazine (which apparently can link to Flathub without problems).
Also, having a Workstation product without a pre-installed video player
is
guaranteed to get bad press (and I don't mean just journalists, but user opinions). Suddenly, "Fedora" can't even play open-source codecs by
default.
Our mission is to "advance software and content freedom", but we
wouldn't be
even able to play FOSS content out-of-the-box? That's really... weird.
Not to find false equivalences, but we don't ship with a mail client out-of-the-box either.
I'd really rather not have the application available in Fedora, than
have it
be a cut-down version that's really hard to extend. In the end, the
end-users
will go the way you mentioned earlier, look for a video player, and end
up
installing VLC from Flathub, instead of trying to figure out why this
sucky
video player couldn't play anything.
It seems ironic to me that such a proposal would arrive in a time when
we're
in the best situation ever, compared to history. Many codecs patents
expired
lately (mostly audio, true) and we can play them reasonably well. VP8
and
VP9 are used on a massive scale (YouTube), even though in situations
where
common users don't interact with them (unless you download videos from YouTube, I do). WebM hasn't made the impact we wished for, but you can
still
see it from time to time, particularly with FOSS-related events.
Hopefully
AV1 will change this. Overall, it's not much, yes, but it's still better than it used to be (at least that's my perception). And I believe I saw
a
claim somewhere (can't remember where) that we could get higher profile support in openh264 in a near future (perhaps Christian can comment on this). That would of course flip this whole discussion upside down,
because
suddenly we'd be able to play the most widespread video codec.
There's a long tail of codecs that are not playable on Fedora, and will
probably
never be playable, most of them too niche to be worth spending the time
to look
whether they're covered by patents that are still running, and there's
some
already reasonable amount of videos available online as H265, which we
won't be
able to support for a while.
The support is better than it's been, but it's still far from optimal,
and this
discussion only covers GStreamer codecs and demuxers, which can be
detected and
somewhat automatically installed. We also have the question of other
patent-covered
uses such as video acceleration.
Cheers _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
On Wed, 2019-02-20 at 15:07 +0100, Lukas Ruzicka wrote:
My opinion is that unless there is a replacement for Videos, it should stay there, whatever problems with missing codecs it has. Removing applications because they are not perfect is not a way to go. The way to go is to make the applications perfect, so that they could stay.
You do realize you're talking to the upstream maintainer, and that pointint people to Flathub actually **is** his way of making his application perfect? (or at least better)
I am not a Gnome Video user, I even ain't a Gnome user. but I think our users deserve a good treatment and service.
Indeed. And the version from Flathub will serve them better.
You do realize you're talking to the upstream maintainer, and that pointint people to Flathub actually **is** his way of making his application perfect? (or at least better)
Yes, I know it. And I only wanted to express my opinion, which I did. And I believe that the thread appeared here, because Bastien wanted to hear our opinions. Otherwise he would not have asked.
The reasoning for my opinion is this: When people install Fedora Workstation, they want to use it right away. How would a newbie know, that there is Flatpak? How does it go together with Fedora policy? We cannot ship codecs in packages, and we can ship codecs in Flatpaks? And if not, what is the difference then? If Flatpak Videos is better than an RPM Videos, why not install that from Flatpaks in the default install then?
I am not a Gnome Video user, I even ain't a Gnome user. but I think our users deserve a good treatment and service.
Indeed. And the version from Flathub will serve them better.
-- Mathieu _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
----- Original Message -----
Yes, I know it. And I only wanted to express my opinion, which I did. And I believe that the thread appeared here, because Bastien wanted to hear our opinions. Otherwise he would not have asked.
The reasoning for my opinion is this: When people install Fedora Workstation, they want to use it right away. How would a newbie know, that there is Flatpak?
How does the user know that there is a third-party RPM repository that contains the necessary codecs for the movie player to work?
How does it go together with Fedora policy? We cannot ship codecs in packages, and we can ship codecs in Flatpaks? And if not, what is the difference then?
It's a Flatpak and it's from a third-party repository. Flatpaks from Fedora couldn't ship those, RPMs from a third-party repository likely could.
If Flatpak Videos is better than an RPM Videos, why not install that from Flatpaks in the default install then?
Because we cannot ship, or point to, potentially patent-infringing software in Fedora.
How does the user know that there is a third-party RPM repository that contains the necessary codecs for the movie player to work?
The funny thing is that it **works**. Just with open codecs. Even the stupid Windows have always shipped a movie player in the default installation that users could use for the start.
Our views differ, that's fine with me. Open source is about freedom of choice, too. And time will tell if people stick with Flatpak Totem or choose Flatpak Somethingelse or RPM Fusion Somethingdifferent or even Snap Anotherthing.
My voice have sounded. That's all I needed.
----- Original Message -----
How people will find about it? GNOME Software? if true, why it is fine to show on GNOME Software an application full of patented codecs vs showing a codec pack from rpmfusion? I mean the legal aspects of not adding rpmfusion as a repository are known, but I don't find any difference with flathub then.
They will find it on the Internet. We cannot link to Flathub in Fedora, just as we cannot link to RPMFusion.
On Wed, Feb 20, 2019 at 7:15 AM Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
How people will find about it? GNOME Software? if true, why it is fine to show on GNOME Software an application full of patented codecs vs showing a codec pack from rpmfusion? I mean the legal aspects of not adding rpmfusion as a repository are known, but I don't find any difference with flathub then.
They will find it on the Internet. We cannot link to Flathub in Fedora, just as we cannot link to RPMFusion.
Google 'fedora video player'
flathub doesn't appear in the first five pages of results. So they're going to find it on the internet how?
----- Original Message -----
On Wed, Feb 20, 2019 at 7:15 AM Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
How people will find about it? GNOME Software? if true, why it is fine to show on GNOME Software an application full of patented codecs vs showing a codec pack from rpmfusion? I mean the legal aspects of not adding rpmfusion as a repository are known, but I don't find any difference with flathub then.
They will find it on the Internet. We cannot link to Flathub in Fedora, just as we cannot link to RPMFusion.
Google 'fedora video player'
flathub doesn't appear in the first five pages of results. So they're going to find it on the internet how?
I've already answered this earlier in the thread. You can't Google things that haven't been written and published, that's kind of a given...
On 2/20/19 7:41 AM, Bastien Nocera wrote:
GNOME Videos will still be available, from here: https://flathub.org/apps/details/org.gnome.Totem with all the bells and whistles.
I think that, out-of-the-box, clicking on "Install" on this website will lead to a better experience than 1) finding out about third-party RPM repositories 2) enabling said repositories 3) triggering the codecs to be installed, including the aforementioned PackageKit-gstreamer helper bugs
I intend to advertise the upstream distribution of totem via my own blog, and Fedora Magazine (which apparently can link to Flathub without problems).
I will not install a Flatpak of any kind. Sorry. If you intend to drop maintaining totem in Fedora I'll most likely take maintainership.
Not to find false equivalences, but we don't ship with a mail client out-of-the-box either.
The default Gnome client is terrible and no one uses it, but there are viable alternatives as Fedora native packages. I don't think it's fair to compare e-mail to video. E-mail doesn't have patents involved.
I'd really rather not have the application available in Fedora, than have it be a cut-down version that's really hard to extend. In the end, the end-users will go the way you mentioned earlier, look for a video player, and end up installing VLC from Flathub, instead of trying to figure out why this sucky video player couldn't play anything.
Gstreamer is hard to extend? :-/
Sounds like you want to give up on the automatic codec installation and require users to go digging for third-party software because *you* think it's better. I don't think it's better.
There's a long tail of codecs that are not playable on Fedora, and will probably never be playable, most of them too niche to be worth spending the time to look whether they're covered by patents that are still running, and there's some already reasonable amount of videos available online as H265, which we won't be able to support for a while.
The support is better than it's been, but it's still far from optimal, and this discussion only covers GStreamer codecs and demuxers, which can be detected and somewhat automatically installed. We also have the question of other patent-covered uses such as video acceleration.
We have gstreamer1-vaapi in Fedora so why not install that by default? The latest offerings from Intel or AMD support h264/h265/vp9 decoding with VAAPI.
We also have RPMFusion stuff being suggested and installed today. Why not extend that to the gstreamer1-libav/gstreamer1-plugins-ugly package(s)?
----- Original Message -----
On 2/20/19 7:41 AM, Bastien Nocera wrote:
GNOME Videos will still be available, from here: https://flathub.org/apps/details/org.gnome.Totem with all the bells and whistles.
I think that, out-of-the-box, clicking on "Install" on this website will lead to a better experience than 1) finding out about third-party RPM repositories 2) enabling said repositories 3) triggering the codecs to be installed, including the aforementioned PackageKit-gstreamer helper bugs
I intend to advertise the upstream distribution of totem via my own blog, and Fedora Magazine (which apparently can link to Flathub without problems).
I will not install a Flatpak of any kind. Sorry. If you intend to drop maintaining totem in Fedora I'll most likely take maintainership.
I'm not interested in somebody taking over the package. If that was the only thing I was interested in, I would already have orphaned it.
Not to find false equivalences, but we don't ship with a mail client out-of-the-box either.
The default Gnome client is terrible and no one uses it, but there are viable alternatives as Fedora native packages. I don't think it's fair to compare e-mail to video. E-mail doesn't have patents involved.
"The default Gnome client is terrible and no one uses it"
This sort of statement pretty much invalidates any other statement you might make in this email. It's just beyond silly.
I'd really rather not have the application available in Fedora, than have it be a cut-down version that's really hard to extend. In the end, the end-users will go the way you mentioned earlier, look for a video player, and end up installing VLC from Flathub, instead of trying to figure out why this sucky video player couldn't play anything.
Gstreamer is hard to extend? :-/
It's hard for end-users to know what to install, where to install it from, and how to get those GStreamer plugins installed.
Sounds like you want to give up on the automatic codec installation and require users to go digging for third-party software because *you* think it's better. I don't think it's better.
The end-user interaction would be better by making them install from Flathub, rather than trying to figure out how to install codecs from a third-party repository. I don't _think_ it's better, I know it to be better.
There's a long tail of codecs that are not playable on Fedora, and will probably never be playable, most of them too niche to be worth spending the time to look whether they're covered by patents that are still running, and there's some already reasonable amount of videos available online as H265, which we won't be able to support for a while.
The support is better than it's been, but it's still far from optimal, and this discussion only covers GStreamer codecs and demuxers, which can be detected and somewhat automatically installed. We also have the question of other patent-covered uses such as video acceleration.
We have gstreamer1-vaapi in Fedora so why not install that by default? The latest offerings from Intel or AMD support h264/h265/vp9 decoding with VAAPI.
They don't work unless you install additional drivers which aren't available in Fedora.
We also have RPMFusion stuff being suggested and installed today. Why not extend that to the gstreamer1-libav/gstreamer1-plugins-ugly package(s)?
No we don't. RPMFusion is not linked from anywhere in the Fedora installations.
On 2/20/19 8:22 AM, Bastien Nocera wrote:
This sort of statement pretty much invalidates any other statement you might make in this email. It's just beyond silly.
I see you have your typical, terse hat on today and no discussion will be fruitful. This will be my last reply.
It's hard for end-users to know what to install, where to install it from, and how to get those GStreamer plugins installed.
This statement makes your statements about installing Flatpaks ironic.
The end-user interaction would be better by making them install from Flathub, rather than trying to figure out how to install codecs from a third-party repository. I don't_think_ it's better, I know it to be better.
There's nothing positive I can say about this statement. Luckily Fedora allows the many to do things the right way when others feel they know everything.
They don't work unless you install additional drivers which aren't available in Fedora.
I'm fully aware of this. My hands are involved in a few packages that use this functionality.
We also have RPMFusion stuff being suggested and installed today. Why not extend that to the gstreamer1-libav/gstreamer1-plugins-ugly package(s)?
No we don't. RPMFusion is not linked from anywhere in the Fedora installations.
https://fedoraproject.org/wiki/Workstation/Third_Party_Software_Repositories
----- Original Message -----
On 2/20/19 8:22 AM, Bastien Nocera wrote:
This sort of statement pretty much invalidates any other statement you might make in this email. It's just beyond silly.
I see you have your typical, terse hat on today and no discussion will be fruitful. This will be my last reply.
Seriously, you're going to "tu quoque" me after you called Evolution something "terrible that nobody uses". Anyway, there's more below, a bit less terse.
It's hard for end-users to know what to install, where to install it from, and how to get those GStreamer plugins installed.
This statement makes your statements about installing Flatpaks ironic.
Absolutely not. Let me break it down.
No totem in distribution ------------------------
1. Try to play videos and realise there's nothing installed to play them 2. Launch browser, search for fedora video player 3. Find Fedora Magazine, a blog post, or a forum, linking to Flathub version of GNOME Videos 4. Click on link 5. Click install button, and a few more buttons 6. Application is installed
(Note that at 1. you might end up launching something that looks like gnome-software --search=video/mp4 which unfortunately would show some equally under-featured movie players, which might be a problem that would need fixing)
totem in distribution ---------------------
1. Try to play videos and have an error thrown saying they can't be played 2. Click on "search" for "additional codecs" 3. Find nothing in GNOME Software, close it 4. Launch browser, search for fedora + "error message" 5. Find Fedora Magazine, a blog post, or a forum, linking to RPMFusion 6. Click on link to RPMFusion 7. Click on "Enable RPM Fusion on your system" 8. Click on "RPM Fusion free for Fedora XX" 9. Click install 10. Click on "RPM Fusion nonfree for Fedora XX" 11. Click install 12. Try to play videos and have an error thrown saying they can't be played 13. Click on "search" for "additional codecs" 14. Click on first result, click install, click back 15. Repeat 14. for every item in the list (missing audio/video codecs might be in different packages) 16. Close GNOME Software 17. Click play, realise that it won't play 18. Close video player 19. Try to play videos again, it works
If PackageKit-gstreamer and the GNOME Software integration was fixed, it would play the video at 17.
The end-user interaction would be better by making them install from Flathub, rather than trying to figure out how to install codecs from a third-party repository. I don't_think_ it's better, I know it to be better.
There's nothing positive I can say about this statement. Luckily Fedora allows the many to do things the right way when others feel they know everything.
For this case, yes, I worked with Thomas on the original "missing plugins" support for GStreamer, which we added in Fedora 12 years ago. See the workflow above and tell me that installing GStreamer plugins is easier than installing the Flatpak.
They don't work unless you install additional drivers which aren't available in Fedora.
I'm fully aware of this. My hands are involved in a few packages that use this functionality.
This also means that it's another thing to manually download and configure.
We also have RPMFusion stuff being suggested and installed today. Why not extend that to the gstreamer1-libav/gstreamer1-plugins-ugly package(s)?
No we don't. RPMFusion is not linked from anywhere in the Fedora installations.
https://fedoraproject.org/wiki/Workstation/Third_Party_Software_Repositories
It's a subset of RPMFusion, the end-user never actually sees a link to rpmfusion.org.
----- Original Message -----
On 2/20/19 8:22 AM, Bastien Nocera wrote:
totem in distribution
- Try to play videos and have an error thrown saying they can't be played
- Click on "search" for "additional codecs"
- Find nothing in GNOME Software, close it
- Launch browser, search for fedora + "error message"
- Find Fedora Magazine, a blog post, or a forum, linking to RPMFusion
- Click on link to RPMFusion
- Click on "Enable RPM Fusion on your system"
- Click on "RPM Fusion free for Fedora XX"
- Click install
- Click on "RPM Fusion nonfree for Fedora XX"
- Click install
- Try to play videos and have an error thrown saying they can't be played
- Click on "search" for "additional codecs"
- Click on first result, click install, click back
- Repeat 14. for every item in the list (missing audio/video codecs
might be in different packages) 16. Close GNOME Software 17. Click play, realise that it won't play 18. Close video player 19. Try to play videos again, it works
Or, something like this maybe? 1. Try to play videos and have an error thrown saying they can't be played 2. Google Fedora media player 3. Get to either Totem/VLC flathub pages with all the codecs 4. Click on install button 5. Profit
I don't see the benefit of removing Totem from Fedora, it is just going to hurt users who play files encoded in some open format. It is not going to help anybody else.
----- Original Message -----
----- Original Message -----
On 2/20/19 8:22 AM, Bastien Nocera wrote:
totem in distribution
- Try to play videos and have an error thrown saying they can't be played
- Click on "search" for "additional codecs"
- Find nothing in GNOME Software, close it
- Launch browser, search for fedora + "error message"
- Find Fedora Magazine, a blog post, or a forum, linking to RPMFusion
- Click on link to RPMFusion
- Click on "Enable RPM Fusion on your system"
- Click on "RPM Fusion free for Fedora XX"
- Click install
- Click on "RPM Fusion nonfree for Fedora XX"
- Click install
- Try to play videos and have an error thrown saying they can't be played
- Click on "search" for "additional codecs"
- Click on first result, click install, click back
- Repeat 14. for every item in the list (missing audio/video codecs might
be in different packages) 16. Close GNOME Software 17. Click play, realise that it won't play 18. Close video player 19. Try to play videos again, it works
Or, something like this maybe?
- Try to play videos and have an error thrown saying they can't be played
- Google Fedora media player
- Get to either Totem/VLC flathub pages with all the codecs
- Click on install button
- Profit
That's a possibility, yes.
I don't see the benefit of removing Totem from Fedora, it is just going to hurt users who play files encoded in some open format. It is not going to help anybody else.
Making sure the 17- or 19-step flow can't happen is a pretty big one.
In any case, one of two things needs to happen: - either we keep totem in, and somebody needs to fix PackageKit-gstreamer to actually follow the interface it needs to have - or we remove totem, and we need to figure out what to do with that "search for movie players" link into GNOME Software
On 2/20/19 11:12 AM, Bastien Nocera wrote:
----- Original Message -----
On 2/20/19 8:22 AM, Bastien Nocera wrote:
This sort of statement pretty much invalidates any other statement you might make in this email. It's just beyond silly.
I see you have your typical, terse hat on today and no discussion will be fruitful. This will be my last reply.
Seriously, you're going to "tu quoque" me after you called Evolution something "terrible that nobody uses". Anyway, there's more below, a bit less terse.
It's hard for end-users to know what to install, where to install it from, and how to get those GStreamer plugins installed.
This statement makes your statements about installing Flatpaks ironic.
Absolutely not. Let me break it down.
No totem in distribution
- Try to play videos and realise there's nothing installed to play them
- Launch browser, search for fedora video player
- Find Fedora Magazine, a blog post, or a forum, linking to Flathub version of GNOME Videos
- Click on link
- Click install button, and a few more buttons
- Application is installed
(Note that at 1. you might end up launching something that looks like gnome-software --search=video/mp4 which unfortunately would show some equally under-featured movie players, which might be a problem that would need fixing)
totem in distribution
This could be simplified a lot with the help of rpmfusion:
1. Try to play videos and have an error thrown saying they can't be played 2. Launch browser, search for Fedora video player plugins 3. Find Fedora Magazine, a blog post, or a forum, linking to an rpmfusion package for video codecs. 4. Install the package that adds the rpmfusion repositories and pull all recommended dependencies, so it is a meta package with all plugins as requirements
You will not get only Totem ready, but Firefox H.264 (OpenH264 is only for WebRTC)
- Try to play videos and have an error thrown saying they can't be played
- Click on "search" for "additional codecs"
- Find nothing in GNOME Software, close it
- Launch browser, search for fedora + "error message"
- Find Fedora Magazine, a blog post, or a forum, linking to RPMFusion
- Click on link to RPMFusion
- Click on "Enable RPM Fusion on your system"
- Click on "RPM Fusion free for Fedora XX"
- Click install
- Click on "RPM Fusion nonfree for Fedora XX"
- Click install
- Try to play videos and have an error thrown saying they can't be played
- Click on "search" for "additional codecs"
- Click on first result, click install, click back
- Repeat 14. for every item in the list (missing audio/video codecs might be in different packages)
- Close GNOME Software
- Click play, realise that it won't play
- Close video player
- Try to play videos again, it works
If PackageKit-gstreamer and the GNOME Software integration was fixed, it would play the video at 17.
The end-user interaction would be better by making them install from Flathub, rather than trying to figure out how to install codecs from a third-party repository. I don't_think_ it's better, I know it to be better.
There's nothing positive I can say about this statement. Luckily Fedora allows the many to do things the right way when others feel they know everything.
For this case, yes, I worked with Thomas on the original "missing plugins" support for GStreamer, which we added in Fedora 12 years ago. See the workflow above and tell me that installing GStreamer plugins is easier than installing the Flatpak.
They don't work unless you install additional drivers which aren't available in Fedora.
I'm fully aware of this. My hands are involved in a few packages that use this functionality.
This also means that it's another thing to manually download and configure.
We also have RPMFusion stuff being suggested and installed today. Why not extend that to the gstreamer1-libav/gstreamer1-plugins-ugly package(s)?
No we don't. RPMFusion is not linked from anywhere in the Fedora installations.
https://fedoraproject.org/wiki/Workstation/Third_Party_Software_Repositories
It's a subset of RPMFusion, the end-user never actually sees a link to rpmfusion.org. _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
----- Original Message -----
This could be simplified a lot with the help of rpmfusion:
- Try to play videos and have an error thrown saying they can't be played
- Launch browser, search for Fedora video player plugins
- Find Fedora Magazine, a blog post, or a forum, linking to an
rpmfusion package for video codecs. 4. Install the package that adds the rpmfusion repositories and pull all recommended dependencies, so it is a meta package with all plugins as requirements
You will not get only Totem ready, but Firefox H.264 (OpenH264 is only for WebRTC)
That's certainly possible, but would require changes in GNOME Software/ PackageKit and the website. Who will do this work?
On 2/20/19 11:43 AM, Bastien Nocera wrote:
----- Original Message -----
This could be simplified a lot with the help of rpmfusion:
- Try to play videos and have an error thrown saying they can't be played
- Launch browser, search for Fedora video player plugins
- Find Fedora Magazine, a blog post, or a forum, linking to an
rpmfusion package for video codecs. 4. Install the package that adds the rpmfusion repositories and pull all recommended dependencies, so it is a meta package with all plugins as requirements
You will not get only Totem ready, but Firefox H.264 (OpenH264 is only for WebRTC)
That's certainly possible, but would require changes in GNOME Software/ PackageKit and the website. Who will do this work?
I would help with creating a meta package for rpmfusion and see if the are interested on pushing it on the front page like they do for the free and non free repo packages.
If we add another step, after adding the repository meta package:
5. go to GNOME Software and install the new meta package there
It is no different than adding your first flathub package, first add the repo, then install the meta package. No need for Software changes.
I have my own list of plugins from rpmfusion I install, If people have recommendations of which one they install for another format I don't use. Please reply with information about them, and what format you think are they helpful
This are the one I use for my requirements:
gstreamer1-libav.x86_64 gstreamer1-plugins-bad-free
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
----- Original Message -----
On 2/20/19 7:41 AM, Bastien Nocera wrote:.
"The default Gnome client is terrible and no one uses it"
This sort of statement pretty much invalidates any other statement you might make in this email. It's just beyond silly.
It might invalidate his other statements for you, fine, but that does not mean it invalidates anything for others. There is nothing wrong with expressing personal opinions. Yeah, the sentence "no one uses it" is probably not based on actual data, but that does not mean that Michael might not have valid arguments.
It's hard for end-users to know what to install, where to install it from,
and how to get those GStreamer plugins installed.
Is it more difficult than installing Totem from elsewhere? I don't think so.
The end-user interaction would be better by making them install from Flathub, rather than trying to figure out how to install codecs from a third-party repository. I don't _think_ it's better, I know it to be better.
And I know it is not. It's still far better to at least have some media player included by default, even if it's not able to play every media file that user has.
----- Original Message -----
Is it more difficult than installing Totem from elsewhere? I don't think so.
It is, see my most recent mail.
If we were comparing installing GStreamer codecs for totem and others from an RPM repository, vs. installing another video player from an RPM repository, then I would have agreed that it's equally as complicated.
But installing from something like Flathub, or another Flatpak source is trivial.
st 20. úno 2019 16:27 odesílatel Bastien Nocera bnocera@redhat.com napsal:
But installing from something like Flathub, or another Flatpak source is trivial.
It seems like here is the core. Sorry, but now it looks like you are just trying to promote Flatpacks over anything else. I find RPM fusion even more trivial for example.
_______________________________________________
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
----- Original Message -----
st 20. úno 2019 16:27 odesílatel Bastien Nocera < bnocera@redhat.com > napsal:
But installing from something like Flathub, or another Flatpak source is trivial.
It seems like here is the core. Sorry, but now it looks like you are just trying to promote Flatpacks over anything else. I find RPM fusion even more trivial for example.
It is where we're going already. We've already started generating Flatpaks in Fedora. I'm not certain why this comes as a surprise.
Providing Flatpacks besides RPMs to increase the variability of options for users is a good thing, but getting rid of everything which is not Flatpacks, taking the options away, is not only a surprise for me, it is also quite disturbing. For me, that goes against the idea of Linux and what I like about it.
st 20. úno 2019 16:43 odesílatel Bastien Nocera bnocera@redhat.com napsal:
----- Original Message -----
st 20. úno 2019 16:27 odesílatel Bastien Nocera < bnocera@redhat.com > napsal:
But installing from something like Flathub, or another Flatpak source
is
trivial.
It seems like here is the core. Sorry, but now it looks like you are just trying to promote Flatpacks over anything else. I find RPM fusion even
more
trivial for example.
It is where we're going already. We've already started generating Flatpaks in Fedora. I'm not certain why this comes as a surprise. _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
----- Original Message -----
Providing Flatpacks besides RPMs to increase the variability of options for users is a good thing, but getting rid of everything which is not Flatpacks, taking the options away, is not only a surprise for me, it is also quite disturbing. For me, that goes against the idea of Linux and what I like about it.
RPMs don't work on Fedora Silverblue. RPMs will likely become the base from which you generate a base OS, or Flatpaks...
Ok, when people want Silverblue, they will use Flatpaks. I say not a single word against it. What I advocate here for is the freedom of choice. Some want this and others want that and our task is to make both happy.
st 20. úno 2019 16:58 odesílatel Bastien Nocera bnocera@redhat.com napsal:
----- Original Message -----
Providing Flatpacks besides RPMs to increase the variability of options
for
users is a good thing, but getting rid of everything which is not
Flatpacks,
taking the options away, is not only a surprise for me, it is also quite disturbing. For me, that goes against the idea of Linux and what I like about it.
RPMs don't work on Fedora Silverblue. RPMs will likely become the base from which you generate a base OS, or Flatpaks... _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
On Wed, Feb 20, 2019 at 2:41 PM Bastien Nocera bnocera@redhat.com wrote:
GNOME Videos will still be available, from here: https://flathub.org/apps/details/org.gnome.Totem with all the bells and whistles.
I think that, out-of-the-box, clicking on "Install" on this website will lead to a better experience than 1) finding out about third-party RPM repositories 2) enabling said repositories 3) triggering the codecs to be installed, including the aforementioned PackageKit-gstreamer helper bugs
That's probably true. And users who already know about this can do it already. But without desktop integration, it's unlikely we can get this message through to most of our users. Of course, spreading this information doesn't mean the default player needs to get removed. The player can be there, "half-functional", and we can do our best to inform our users how to improve the state (even if that means removing the pre-installed one and installing its Flathub version, that's just one extra step compared to your guide).
(Whether we can spread this information or not, link to Flathub with apps containing patented codecs, etc, is something that people with legal background should probably decide, I have no idea.)
But, one important thing should be considered. Many of those people who install patented codecs into Fedora will need to enable the system repositories anyway, Flathub's Totem or VLC will not be enough. And that's because web is the king now, and web browsers need those codecs to play most of the web's video content (except YouTube). Except Chrome, which is popular, but probably not something we want to encourage.
So I think a large number of users will need to find third-party codecs anyway (which "fixes" many apps including Totem), and asking them to install Totem from Flathub doesn't change the picture that much.
I intend to advertise the upstream distribution of totem via my own blog, and Fedora Magazine (which apparently can link to Flathub without problems).
Also, having a Workstation product without a pre-installed video player
is
guaranteed to get bad press (and I don't mean just journalists, but user opinions). Suddenly, "Fedora" can't even play open-source codecs by
default.
Our mission is to "advance software and content freedom", but we
wouldn't be
even able to play FOSS content out-of-the-box? That's really... weird.
Not to find false equivalences, but we don't ship with a mail client out-of-the-box either.
I'd really rather not have the application available in Fedora, than have it be a cut-down version that's really hard to extend. In the end, the end-users will go the way you mentioned earlier, look for a video player, and end up installing VLC from Flathub, instead of trying to figure out why this sucky video player couldn't play anything.
OK, I think I understand now the reason of this proposal. You don't want Totem to be seen as a broken application, you're the main developer. I can relate to that. Personally, even though Totem doesn't have enough features for me, it's consistently more reliable for me than VLC. However, I still believe we should have a video player installed by default, and Totem is a good fit.
Kamil Paral píše v St 20. 02. 2019 v 15:22 +0100:
On Wed, Feb 20, 2019 at 2:41 PM Bastien Nocera bnocera@redhat.com wrote:
GNOME Videos will still be available, from here: https://flathub.org/apps/details/org.gnome.Totem with all the bells and whistles.
I think that, out-of-the-box, clicking on "Install" on this website will lead to a better experience than 1) finding out about third-party RPM repositories 2) enabling said repositories 3) triggering the codecs to be installed, including the aforementioned PackageKit-gstreamer helper bugs
That's probably true. And users who already know about this can do it already. But without desktop integration, it's unlikely we can get this message through to most of our users. Of course, spreading this information doesn't mean the default player needs to get removed. The player can be there, "half-functional", and we can do our best to inform our users how to improve the state (even if that means removing the pre-installed one and installing its Flathub version, that's just one extra step compared to your guide).
(Whether we can spread this information or not, link to Flathub with apps containing patented codecs, etc, is something that people with legal background should probably decide, I have no idea.)
But, one important thing should be considered. Many of those people who install patented codecs into Fedora will need to enable the system repositories anyway, Flathub's Totem or VLC will not be enough. And that's because web is the king now, and web browsers need those codecs to play most of the web's video content (except YouTube). Except Chrome, which is popular, but probably not something we want to encourage.
So I think a large number of users will need to find third-party codecs anyway (which "fixes" many apps including Totem), and asking them to install Totem from Flathub doesn't change the picture that much.
This is a good point. I'd say that these days people watch videos more in a browser than in a desktop player and installing anything from Flathub is currently not going to help them in any way. Firefox and Chromium rely on libavcodec in the system. No matter if Totem is included or installed from Flathub, nothing changes for them: Wanna play videos? Go and enable that 3rd party repo and install ffmpeg. And once that repo is enabled, Software can AFAIK install required GStreamer plugins in a few clicks.
I also wonder whether we should continue in our efforts to include as many video codecs as legally possible (adding support for H.264 playback etc.). What would the consumer of it? Totem would be gone and browsers use libavcodec.
Jiri
----- Original Message -----
This is a good point. I'd say that these days people watch videos more in a browser than in a desktop player and installing anything from Flathub is currently not going to help them in any way. Firefox and Chromium rely on libavcodec in the system. No matter if Totem is included or installed from Flathub, nothing changes for them: Wanna play videos? Go and enable that 3rd party repo and install ffmpeg. And once that repo is enabled, Software can AFAIK install required GStreamer plugins in a few clicks.
I also wonder whether we should continue in our efforts to include as many video codecs as legally possible (adding support for H.264 playback etc.). What would the consumer of it? Totem would be gone and browsers use libavcodec.
Firefox can also use OpenH264, so it should be able to play more things in the future. However, the breadth of codecs a web browser needs is not the same as the one required for a movie player in any case, so that still wouldn't quite be enough.
And I'm guessing that for most users, there's no figuring out why Firefox can't play things, it goes straight to installing a browser that can play those things, usually Google Chrome.
We ship: Firefox, GNOME Videos Users probably end up installing (from Google, RPMFusion or somewhere else): Chrome, VLC
On 20/02/19 16:49, Jiri Eischmann wrote:
Kamil Paral píše v St 20. 02. 2019 v 15:22 +0100:
On Wed, Feb 20, 2019 at 2:41 PM Bastien Nocera bnocera@redhat.com wrote:
GNOME Videos will still be available, from here: https://flathub.org/apps/details/org.gnome.Totem with all the bells and whistles.
I think that, out-of-the-box, clicking on "Install" on this website will lead to a better experience than 1) finding out about third-party RPM repositories 2) enabling said repositories 3) triggering the codecs to be installed, including the aforementioned PackageKit-gstreamer helper bugs
That's probably true. And users who already know about this can do it already. But without desktop integration, it's unlikely we can get this message through to most of our users. Of course, spreading this information doesn't mean the default player needs to get removed. The player can be there, "half-functional", and we can do our best to inform our users how to improve the state (even if that means removing the pre-installed one and installing its Flathub version, that's just one extra step compared to your guide).
(Whether we can spread this information or not, link to Flathub with apps containing patented codecs, etc, is something that people with legal background should probably decide, I have no idea.)
But, one important thing should be considered. Many of those people who install patented codecs into Fedora will need to enable the system repositories anyway, Flathub's Totem or VLC will not be enough. And that's because web is the king now, and web browsers need those codecs to play most of the web's video content (except YouTube). Except Chrome, which is popular, but probably not something we want to encourage.
So I think a large number of users will need to find third-party codecs anyway (which "fixes" many apps including Totem), and asking them to install Totem from Flathub doesn't change the picture that much.
This is a good point. I'd say that these days people watch videos more in a browser than in a desktop player and installing anything from Flathub is currently not going to help them in any way. Firefox and Chromium rely on libavcodec in the system. No matter if Totem is included or installed from Flathub, nothing changes for them: Wanna play videos? Go and enable that 3rd party repo and install ffmpeg. And once that repo is enabled, Software can AFAIK install required GStreamer plugins in a few clicks.
This is not that easy with Silverblue. You need to install rpmfusion RPMs first, than reboot, install ffmpeg, reboot. I'm still waiting for Firefox in flatpak to be a think.
Anyway, Silverblue is now installed with only few applications - Firefox, Gnome-software and some utilities function. So first thing you need to do is to add some Flatpak repository (and rpmfusion if you want Firefox with codecs). I really like the Silverblue, it's awesome concept, but it still needs some work.
As normal end user I would expect to have at least option to install what I want out of the box.
mkonecny
I also wonder whether we should continue in our efforts to include as many video codecs as legally possible (adding support for H.264 playback etc.). What would the consumer of it? Totem would be gone and browsers use libavcodec.
Jiri _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
On Wed, Feb 20, 2019 at 02:02:57PM +0100, Kamil Paral wrote:
default. Our mission is to "advance software and content freedom", but we wouldn't be even able to play FOSS content out-of-the-box? That's really... weird.
Our mission is to create an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.
Freedom is one of our fundamental values and we certainly want to promote that. But if we don't have a good solution... well, sometimes we don't.
On Wed, Feb 20, 2019, 19:03 Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Feb 20, 2019 at 02:02:57PM +0100, Kamil Paral wrote:
default. Our mission is to "advance software and content freedom", but we wouldn't be even able to play FOSS content out-of-the-box? That's
really...
weird.
Our mission is to create an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.
Freedom is one of our fundamental values and we certainly want to promote that. But if we don't have a good solution... well, sometimes we don't.
But we have a good solution for playing FOSS content. It's called Totem and it works just fine :)
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
I just want to bring a point that may be relevant. At some point I asked @csoriano if video thumbnailing would move to the core of nautilus because I usually prefer another media player, however, their response was that totem is part of the core and if it is not included in the distribution it should be considered a bug. Thumbnailing is something desired for new users and it may be the case that a user simply installs an alternative media player and does not know that totem is "necessary" to provide this functionality in the file manager.
El mié., 20 de feb. de 2019 a la(s) 16:31, Frantisek Zatloukal ( fzatlouk@redhat.com) escribió:
On Wed, Feb 20, 2019, 19:03 Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Feb 20, 2019 at 02:02:57PM +0100, Kamil Paral wrote:
default. Our mission is to "advance software and content freedom", but
we
wouldn't be even able to play FOSS content out-of-the-box? That's
really...
weird.
Our mission is to create an innovative platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.
Freedom is one of our fundamental values and we certainly want to promote that. But if we don't have a good solution... well, sometimes we don't.
But we have a good solution for playing FOSS content. It's called Totem and it works just fine :)
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
----- Original Message -----
I just want to bring a point that may be relevant. At some point I asked @csoriano if video thumbnailing would move to the core of nautilus because I usually prefer another media player, however, their response was that totem is part of the core and if it is not included in the distribution it should be considered a bug. Thumbnailing is something desired for new users and it may be the case that a user simply installs an alternative media player and does not know that totem is "necessary" to provide this functionality in the file manager.
This would obviously be fixed if totem wasn't in the core. I've already fixed it weeks ago for Flatpaks that need video thumbnailing: https://gitlab.gnome.org/GNOME/totem-video-thumbnailer
Problem being that, as it stands, it has the same problems as totem without any way to trigger downloading and installing codecs.
On Thu, Feb 21, 2019 at 9:07 AM Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
I just want to bring a point that may be relevant. At some point I asked @csoriano if video thumbnailing would move to the core of nautilus
because I
usually prefer another media player, however, their response was that
totem
is part of the core and if it is not included in the distribution it
should
be considered a bug. Thumbnailing is something desired for new users and
it
may be the case that a user simply installs an alternative media player
and
does not know that totem is "necessary" to provide this functionality in
the
file manager.
This would obviously be fixed if totem wasn't in the core. I've already fixed it weeks ago for Flatpaks that need video thumbnailing: https://gitlab.gnome.org/GNOME/totem-video-thumbnailer
Problem being that, as it stands, it has the same problems as totem without any way to trigger downloading and installing codecs.
So, do I understand correctly that if you install Totem from Flatpak, there will be no thumbnails in Nautilus? For thumbnails, you need codecs installed locally in the system? That would be another argument for improving the local codecs installation procedure/guide, instead of trying to rely on Flatpaks (which only solve part of the story).
In any case, one of two things needs to happen:
- either we keep totem in, and somebody needs to fix PackageKit-gstreamer to actually follow the interface it needs to have
- or we remove totem, and we need to figure out what to do with that "search for movie players" link into GNOME Software
I don't understand why you paint it as the only two available options. The first one is an improvement, yes. The second one is a decline (at least in my eyes). We can still keep the current state (not ideal, but still better than the second option). Or perhaps do something else (like the virtual package in rpmfusion which can be easily installed and provide good guides in many places, improve messaging in totem when a codec is not found, etc).
On Thu, 21 Feb 2019 at 09:41, Kamil Paral kparal@redhat.com wrote:
I don't understand why you paint it as the only two available options
Couldn't we also fix the gnome-software interface used by the codec installer to only return from the dbus request when the codecs are actually installed? It just sounds like a bug to me...
Richard.
----- Original Message -----
On Thu, 21 Feb 2019 at 09:41, Kamil Paral kparal@redhat.com wrote:
I don't understand why you paint it as the only two available options
Couldn't we also fix the gnome-software interface used by the codec installer to only return from the dbus request when the codecs are actually installed? It just sounds like a bug to me...
That's what I meant by "fix PackageKit-gstreamer", not having looked at the PackageKit code, or what it calls.
This is the bug that's already open: https://bugs.freedesktop.org/show_bug.cgi?id=100791 https://github.com/hughsie/PackageKit/issues/275
----- Original Message -----
So, do I understand correctly that if you install Totem from Flatpak, there will be no thumbnails in Nautilus? For thumbnails, you need codecs installed locally in the system? That would be another argument for improving the local codecs installation procedure/guide, instead of trying to rely on Flatpaks (which only solve part of the story).
This is a packaging bug, nautilus (packaged as an RPM) should depend on the thumbnailers for the formats it wants to show thumbnails for. For example, out-of-the-box, there's no thumbnailers for epubs but there's one for comic books and PDFs.
I don't understand why you paint it as the only two available options. The first one is an improvement, yes. The second one is a decline (at least in my eyes). We can still keep the current state (not ideal, but still better than the second option). Or perhaps do something else (like the virtual package in rpmfusion which can be easily installed and provide good guides in many places, improve messaging in totem when a codec is not found, etc).
Those are the only 2 options if we want to make things better. Your example of something else would still require fixing the automatic codecs installation flow.
Our mission is to create an innovative platform for hardware, clouds, and
containers that enables software developers and community members to build tailored solutions for their users.
I am not sure whether I understand correctly. Are you saying that Fedora is, by our mission, a distribution made for hardware (whatever it means), *clouds* and *containers*? Since when? The Fedora landing page at fedoraproject.org, that is redirected to getfedora.org, says by the way:
- Fedora Workstation is a polished, easy to use operating system for laptop and desktop computers, with a complete set of tools for developers and makers of all kinds.
I do not understand where "*laptop and desktop computers*" and "*complete set of tools for developers and makers of all kinds*" meets clouds and containers only. So either clouds and containers a just a part of what we strive for, or the information on that web site is wrong and outdated and should be corrected.
Having a multimedia player in standard desktop installation goes, I think, well with the "easy to use operating system" statement. Therefore, I tried to advocate for a multimedia player in default Workstation.
And as far as FREEDOM is concerned, it is written in the biggest letters on that page - *Choose Freedom, choose Fedora*. According to that statement, freedom should go before everything else! Limiting freedom in favour of better solutions (when they are still questionable) is not a good way to go as far as I believe.
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
On Wed, Feb 20, 2019 at 7:02 AM, Kamil Paral kparal@redhat.com wrote:
And I believe I saw a claim somewhere (can't remember where) that we could get higher profile support in openh264 in a near future (perhaps Christian can comment on this). That would of course flip this whole discussion upside down, because suddenly we'd be able to play the most widespread video codec.
I don't think I'm the best person to comment on this, but since nobody else has chimed in: that is indeed something the working group is expecting. Unless I'm mistaken, this should really improve the usefulness of totem in a default configuration of Fedora.
Michael
----- Original Message -----
On Wed, Feb 20, 2019 at 7:02 AM, Kamil Paral kparal@redhat.com wrote:
And I believe I saw a claim somewhere (can't remember where) that we could get higher profile support in openh264 in a near future (perhaps Christian can comment on this). That would of course flip this whole discussion upside down, because suddenly we'd be able to play the most widespread video codec.
I don't think I'm the best person to comment on this, but since nobody else has chimed in: that is indeed something the working group is expecting. Unless I'm mistaken, this should really improve the usefulness of totem in a default configuration of Fedora.
"default" though. It's not on disk after an installation. You still need the codecs installation framework to work properly for this to get pulled in. At least you don't need to search and install a separate repository for this.
The solution to the first two problems you listed would be a simple mapping between both the MIME type and a rpm package name just under the existing GStreamer API. Implementing that should be quite simple. With a bit of additional logic, the problem number 3 may be solved too.
- PackageKit's plugin installation helper would need to be fixed to match what the API requires
That would be needed anyway, imho.
Some more comments from my side: 1. Many people have RPMFusion repositories enabled because you will need them for other applications too. Video support in Firefox or your favorite audio player requires RPMFusion too. (totem is not meant to take that role and thus is unusable for anything more advanced than playing single files or short list of files). 2. Flathub is a website with fancy "Install" buttons. In the windows world, users have been told never to use these buttons because they often contain malware. Forcing people to use flathub will un-train user security which might backlash once there is malware for linux. Installing software (on both Linux and Windows) is a task which needs to be done by an educated user, not by someone who does not know which software source to trust. 3. Still the old criticism: Flatpak applications have gigantic overhead. Will you be providing several hundreds of megabytes of updates for each and every update in each and every dependency? If you do, you'll loose users with slower than fibre-connected internet will not get updates. If you don't, people will have unpatched security bugs in totem. Also, debugging flatpak applications is quite hard, same for automated crash reporting.
- Still the old criticism: Flatpak applications have gigantic
overhead. Will you be providing several hundreds of megabytes of updates for each and every update in each and every dependency? If you do, you'll loose users with slower than fibre-connected internet will not get updates. If you don't, people will have unpatched security bugs in totem. Also, debugging flatpak applications is quite hard, same for automated crash reporting.
Flatpak uses OSTree which has a very efficient deduplication and deltas, so this is not really a problem. I'm a user with "slower than fibre-connected internet" (6 Mbps at home) and believe me that flatpaks are not really a problem, much more is consumed by GNOME Software downloading RPMs for updates and not using delta RPMs. Moreover flatpaks can be safely automatically updated on the background, so the user won't even know about it.
Jiri
----- Original Message -----
The solution to the first two problems you listed would be a simple mapping between both the MIME type and a rpm package name just under the existing GStreamer API. Implementing that should be quite simple. With a bit of additional logic, the problem number 3 may be solved too.
This is the existing provides helper: https://src.fedoraproject.org/cgit/rpms/gstreamer1.git/tree/gstreamer1.prov which also uses this patch to GStreamer's gst-inspect: https://src.fedoraproject.org/cgit/rpms/gstreamer1.git/tree/gstreamer-inspec...
I doubt this will be simple if you do not already know that mime-types correspond to multimedia containers, not to the codecs used inside those containers.
- PackageKit's plugin installation helper would need to be fixed to match
what the API requires
That would be needed anyway, imho.
Some more comments from my side:
- Many people have RPMFusion repositories enabled because you will need them
for other applications too. Video support in Firefox or your favorite audio player requires RPMFusion too. (totem is not meant to take that role and thus is unusable for anything more advanced than playing single files or short list of files). 2. Flathub is a website with fancy "Install" buttons. In the windows world, users have been told never to use these buttons because they often contain malware. Forcing people to use flathub will un-train user security which might backlash once there is malware for linux. Installing software (on both Linux and Windows) is a task which needs to be done by an educated user, not by someone who does not know which software source to trust. 3. Still the old criticism: Flatpak applications have gigantic overhead. Will you be providing several hundreds of megabytes of updates for each and every update in each and every dependency? If you do, you'll loose users with slower than fibre-connected internet will not get updates. If you don't, people will have unpatched security bugs in totem. Also, debugging flatpak applications is quite hard, same for automated crash reporting. _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
desktop@lists.fedoraproject.org