Tails

#4 Updated by intrigeri 2014-09-22 09:25:21

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…

#7 Updated by BitingBird 2014-10-17 09:54:44

No answer, the feature request is closed.

#9 Updated by intrigeri 2016-05-09 01:42:08

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.

#11 Updated by intrigeri 2019-06-30 16:08:35

> 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 2019-07-18 18:13:22

> * 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 2019-08-04 08:51:55

>> * 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 2019-08-07 17:24:35

> 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 2019-08-09 09:20:01

> 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.

#18 Updated by intrigeri 2020-05-12 13:35:23

Minor data point wrt. “some videos that are not browsable with totem and are only working with vlc”: I recall having this problem in the past with videos created by our own test suite (fast-{forward,backward} would work erratically), but it works just fine on current Debian sid (Totem 3.34.1-2+b1).