Project

General

Profile

Feature #7929

Replace GNOME Videos by VLC

Added by donis about 5 years ago. Updated about 1 month ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
09/21/2014
Due date:
% Done:

0%

Feature Branch:
Type of work:
Discuss
Blueprint:
Starter:
Affected tool:

Description

Hi,

I would like, since a long time, to see vlc included in Tails.

Here are the main reasons why:

- vlc handles subtitles a better way. For example, it's not possible with totem to re-synchro subtitles.
- some videos that are not browsable with totem and are only working with vlc
- see also the request #7923 by johnsmith (btw, thank you johnsmith, I was thinking to request vlc since a long time)
- vlc answers the requierements listed in the FAQ
- vlc is powerfull and well known by common users, which is good for Tails usuability

Potential cons:

- One could use package persitence. But it's not so secure to activate and leave the persistence opened just for friends who want to watch a movie.
- vlc comes with some network features, but AFAIK, Tails does not use transparent proxy anymore, so connections should be blocked.
- vlc requires 57,0 Mo once installed, even with the option --no-install-recommends

Thank you for considering this request,
all the best
donis


Related issues

Related to Tails - Feature #7923: Streaming music player Rejected 09/21/2014
Related to Tails - Feature #14580: Support Video Acceleration API (VA-API) Confirmed 08/31/2017
Related to Tails - Feature #15874: Start looking at snaps/Flatpak for sandboxing Confirmed 08/30/2018

History

#1 Updated by sajolida about 5 years ago

#2 Updated by intrigeri about 5 years ago

  • Subject changed from Chip vlc media player in Tails to Thip VLC media player

#3 Updated by intrigeri about 5 years ago

  • Subject changed from Thip VLC media player to Include VLC media player

#4 Updated by intrigeri about 5 years ago

donis wrote:

- One could use package persitence.

Exactly, this is the common answer to all such requests, when the requested additional package is only useful in corner cases, which is the case for VLC. This feature was precisely meant to address this kind of situations.

But it's not so secure to activate and leave the persistence opened just for friends who want to watch a movie.

In my opinion, this is not part of the design goals of Tails, so not a valid argument as far as this discussion is concerned. If you really want to do that, then you could use read-only persistence to mitigate the risks a little bit. But oh well, someone who has unmonitored physical access to your Tails device can as well install something that logs your persistent volume's passphrase, so...

#5 Updated by intrigeri about 5 years ago

  • Priority changed from Normal to Low

#6 Updated by intrigeri almost 5 years ago

  • Assignee set to donis
  • QA Check set to Info Needed

#7 Updated by BitingBird almost 5 years ago

No answer, the feature request is closed.

#8 Updated by BitingBird almost 5 years ago

  • Status changed from New to Rejected

#9 Updated by intrigeri over 3 years ago

FTR, https://wiki.debian.org/DebianMultimedia/PlayerSupport shows that Totem's general level of support for filetypes is at least as good as VLC's.

#10 Updated by sajolida 3 months ago

  • Subject changed from Include VLC media player to Replace GNOME Videos by VLC
  • Status changed from Rejected to New
  • Assignee deleted (donis)

I'm reopening this ticket after years. Reading back it's history, I feel like we were the one that didn't answer fully to @donis proposal, which was otherwise pretty well argumented, and not the other way around.

My twist here is that I don't think that we should add VLC but rather that we should replace GNOME Videos by VLC.

As an anecdote, this morning I wanted to watch a LibrePlanet video for breakfast. GNOME Videos had crashed on a couple of videos already (as it often does). I tried with VLC and it worked. I don't have a lot of strong data to prove this (nor will I spend a lot of time proving it) but I've seen VLC being much more reliable than GNOME Videos.

As donis pointed out originally, VLC also has many more features than GNOME Videos; while being relatively unobtrusive if you only want to double-click and watch your video. I've used VLC in Tails to:

All things that are currently impossible to do in vanilla Tails.

I also second donis' other argument: VLC is known by common users (pretty much all my non-geek friends have VLC, even on Windows).

VLC was among the most popular Additional Software packages in my analysis from March 2019:

http://lists.autistici.org/message/20190326.173900.138d9b45.en.html

This also proves that more people think that GNOME Videos is not enough for them.

#11 Updated by intrigeri 3 months ago

As an anecdote, this morning I wanted to watch a LibrePlanet video for breakfast. GNOME Videos had crashed on a couple of videos already (as it often does). I tried with VLC and it worked. I don't have a lot of strong data to prove this (nor will I spend a lot of time proving it) but I've seen VLC being much more reliable than GNOME Videos.

Wrt. reliability:

  • I'm not surprised VLC can read some videos that GNOME Videos can't. This is of course the kind of data one can gather when using GNOME Videos first, and VLC as a fallback.
  • Chances are that the opposite is true as well, i.e. VLC will fail to read some videos, that GNOME Videos can read just fine. But to gather such data, one would need to use primarily VLC, and fallback to GNOME Videos.
  • I don't think it's worth spending lots of time proving which one happens more often.
  • I'm inclined to believe that VLC is more reliable because its userbase is bigger so chances are that more robustness bugs are reported and fixed.

Anecdote-wise, personally, my fallback when Totem fails is gnome-mpv. Its GUI is almost identical to GNOME Videos' and its backend is mpv, which is well known to read basically anything you throw at it. If our main reason to switch is reliability, then gnome-mpv could be an almost drop-in replacement, with the advantage (over VLC) that its UI integrates better in a GNOME desktop than VLC, which uses Qt. In passing, this gives nice HiDPI support for free in recent GNOME+Wayland, while supporting HiDPI for Qt on GNOME is not easy (I gave up, personally).

As donis pointed out originally, VLC also has many more features than GNOME Videos; while being relatively unobtrusive if you only want to double-click and watch your video. I've used VLC in Tails to:
[...]
All things that are currently impossible to do in vanilla Tails.

This looks like the kind of advanced features that we would currently be removing from Tails (if they required installing a dedicated package by default) in favour of Additional Software: none of them seem more common than those offered by some packages we've removed from our images recently. So I'm taking this specific argument with a big grain of salt.

Feature-wise: does VLC support downloading subtitles, in a language chosen by the user? Totem does (not sure if we enable the plugin by default but we do ship it). In my experience, it's a basic feature that users who don't speak English much like a lot and use all the time, once they learn about it. gnome-mpv does not support this.

I also second donis' other argument: VLC is known by common users (pretty much all my non-geek friends have VLC, even on Windows).

This is a strong argument in favour of VLC, IMO.

One last and important thing: video players and their dependencies are dangerous things, with a very large attack surface, so security vulnerabilities are commonplace. This is why we ship an AppArmor profile for GNOME Videos. If we switch to another video player, then IMO we should not regress on this front. It happens that the AppArmor profile for GNOME Videos is almost always up-to-date and working because someone (yours truly) uses GNOME Videos on Debian sid and maintains the profile, upstream and in Debian, on his copious free and volunteer time. The same won't be true for another video player. If one (preferably two) FT members use VLC or gnome-mpv on sid as their default video player and want to dive into AppArmor, they could very well maintain the corresponding AppArmor profile. I just want to point out that it's not a given and won't happen for free.

#12 Updated by sajolida 2 months ago

  • Chances are that the opposite is true as well, i.e. VLC will fail to read some videos, that GNOME Videos can read just fine. But to gather such data, one would need to use primarily VLC, and fallback to GNOME Videos.

I'll do that from now and report any finding.

In passing, this gives nice HiDPI support for free in recent GNOME+Wayland, while supporting HiDPI for Qt on GNOME is not easy (I gave up, personally).

Does this mean that VLC would not display as good as GNOME Videos or
gnome-mpv in Wayland or anything else?

Feature-wise: does VLC support downloading subtitles, in a language chosen by the user?

There's a plugin for that (VLSub) which is already included in the
Debian package. I tried it from Tails and managed to get a list of
subtitles options from opensubtitles.org but downloading one fails
(running VLC through torsocks crashes even worse).

I also tried to do that with GNOME Videos and couldn't find how to do
it. So at first sight there's no regression on this front and maybe an
improvement if we managed to get VLSub working in VLC.

I also know people who use VLC as a music player as it has playlist
support which GNOME Videos doesn't have (I can play several MP3 but I
can't see or modify the playlist). So by adding VLC we would also add a
decent music player in Tails.

This is why we ship an AppArmor profile [...]

Right. We can't include VLC in Tails before it has an AppArmor profile.
Did I understand correctly and AppArmor will be enabled by default in
Debian? If so, maybe someone else will contribute an AppArmor profile or
I could ask if they have plans to add one.

#13 Updated by intrigeri about 2 months ago

  • Chances are that the opposite is true as well, i.e. VLC will fail to read some videos, that GNOME Videos can read just fine. But to gather such data, one would need to use primarily VLC, and fallback to GNOME Videos.

I'll do that from now and report any finding.

Great! :)

In passing, this gives nice HiDPI support for free in recent GNOME+Wayland, while supporting HiDPI for Qt on GNOME is not easy (I gave up, personally).

Does this mean that VLC would not display as good as GNOME Videos or gnome-mpv in Wayland

Yes, on HiDPI displays (see HiDPI on https://en.wikipedia.org/wiki/Pixel_density if that's the part that confused you).

I also tried to do that with GNOME Videos and couldn't find how to do it.

This requires enabling the plugin since we don't do that by default: Videos app menu (from the top bar) → Preferences → Plugins → check "Subtitles Downloader".
I've tried it (because it is trivial to enable that plugin in Tails by default, so I thought "why not?") and it does not work: it seems the OpenSubtitles API blocks Tor.
Given VLSub uses opensubtitles.org too, I bet it won't work either.
So the tl;dr is: we can't get subtitles downloading support in Totem nor in VLC, and this is therefore not a relevant criterion.

This is why we ship an AppArmor profile [...]

Did I understand correctly and AppArmor will be enabled by default in Debian?

It is enabled by default in Debian Buster, that was released on July 6, 2019.

If so, maybe someone else will contribute an AppArmor profile

Given AppArmor has been enabled by default in Ubuntu and openSUSE for many years, I doubt that Debian enabling it by default will trigger the positive effect you're hoping for. But who knows :)

or I could ask if they have plans to add one.

Who is "they" in this context?

#14 Updated by sajolida about 2 months ago

Given AppArmor has been enabled by default in Ubuntu and openSUSE for many years, I doubt that Debian enabling it by default will trigger the positive effect you're hoping for. But who knows :)

Good point :(

or I could ask if they have plans to add one.

Who is "they" in this context?

Would the work of building an AppArmor profile for VLC better be done in
Debian or upstream?

#15 Updated by intrigeri about 1 month ago

Would the work of building an AppArmor profile for VLC better be done in Debian or upstream?

In decreasing order of preference:

  1. Ideally, upstream VLC would do it: they're the best placed to know what sort of access their app legitimately needs.
  2. Worst case, this can live in https://gitlab.com/apparmor/apparmor-profiles.
  3. We don't maintain AppArmor profiles in Debian. There might be an exception or two (not at my initiative) but I really don't want to add more to the list.

#16 Updated by intrigeri about 1 month ago

  • Related to Feature #14580: Support Video Acceleration API (VA-API) added

#17 Updated by intrigeri 15 days ago

  • Related to Feature #15874: Start looking at snaps/Flatpak for sandboxing added

Also available in: Atom PDF