The viewing options OP listed should all work with AV1, I think they were just worried by the preset names. Plus, hardware support should only get better.
OP, you should be able to adjust settings after you select a preset, so you can pick different dimensions/frame rates/audio codecs/etc.
Side note, I've found that the matroska container is the easiest one for me to use if I want better subtitle support.
This is the kind of crap that makes me glad flatpak and such exist. I don’t want a maintainer making arbitrary decisions like this, it adds unpredictability and platform inconsistency.
A similar issue I face is that on Debian the python stdlib well.. isn’t all standard. In particular they split off the venv package, and it’s an extra step that adds unnecessary complication. No other Linux distros or other OS do this, it’s so frustrating. I guess someone is super happy they saved a few hundreds kilobytes of disk space though.
I guess someone is super happy they saved a few hundreds kilobytes of disk space though.
Yes. All the people basing docker images off if debian, and trying to get them as small as possible. The splitting up of packages, allows people to only pull in what they need.
Sorry I was way off in my assumption that the venv package is a few hundreds kilobytes. apt is reporting 6144 bytes. 6 kilobytes. Installing python on the base bookworm image is 38.3MB. If you’re already installing python, it’s a rounding error. Also they have a separate python3-minimal package (which saves a laughable 200kb), why are they de-featuring the regular python version when they also have a separate minimal version? It makes zero sense. The python3 package should contain the entire python standard library. If it were supposed to be an addon, it wouldn’t be part of the standard library.
The python3 package should contain the entire python standard library
You are free to use a distro which does not split packages, favorite distro, Arch Linux (btw).
Or, you can install the recommended dependencies of python3. Testing in a container, the python3 package pulls:
root@a72bd55a3c1a:/# apt install python3
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
ca-certificates krb5-locales libexpat1 libgpm2 libgssapi-krb5-2 libk5crypto3
libkeyutils1 libkrb5-3 libkrb5support0 libncursesw6 libnsl2
libpython3-stdlib libpython3.11-minimal libpython3.11-stdlib libreadline8
libsqlite3-0 libssl3 libtirpc-common libtirpc3 media-types openssl
python3-minimal python3.11 python3.11-minimal readline-common
Suggested packages:
gpm krb5-doc krb5-user python3-doc python3-tk python3-venv python3.11-venv
python3.11-doc binutils binfmt-support readline-doc
The following NEW packages will be installed:
ca-certificates krb5-locales libexpat1 libgpm2 libgssapi-krb5-2 libk5crypto3
libkeyutils1 libkrb5-3 libkrb5support0 libncursesw6 libnsl2
libpython3-stdlib libpython3.11-minimal libpython3.11-stdlib libreadline8
libsqlite3-0 libssl3 libtirpc-common libtirpc3 media-types openssl python3
python3-minimal python3.11 python3.11-minimal readline-common
0 upgraded, 26 newly installed, 0 to remove and 18 not upgraded.
python3-venv python3.11-venv
I find it odd, because debian does this by default, actually. They account for usecases like yours, and instead you have to edit a config file or use a command line flag to get it to not install recommended dependencies.
Look at the compatibility of the device you are running it on. Older hardware like the PlayStation Vita, will only work with H.264 AAC.
Handbranks is able to convert this for you with no issues (even on Linux flatpak ftw), and web playback on a Apache2 server is great. But if your planning on watching it on more modern devices, then don't worry too much about it.
If you want hardware decoding, first check what your gpu actually supports. vainfo can be used on Linux for example.
If you have a very new gpu, it might support av1 decoding. This is currently the best codec and alsi free.
Otherwise I'd prefer hevc and then avc, in that order. Vp8 or vp9 might also be supported, but they never caught on much so encoders and decoders are generally worse for them than the equivalents for other codecs.
I don't know any private person who was prosecuted for using hevc or avc. Most likely your hardware manufacturer and other companies already paid for the license to use hevc/avc. If you live in the EU it's even less of a problem as software patents are not a thing here, i.e. you can't patent a way to do things.
Foe audio opus is the best codec at the momenr.
Please make sure to compare the quality before and after decoding. Even using a more efficient codec I'd be wary of a 300mb sized movie.
There's this assumption that these features in some way create some exploitable security issue.
I get the theory behind it: more code and more interoperability and more features &etc. generally leads to more bugs than the alternative, sure.
But there's also a line beyond which that principle stops making sense from a practical standpoint. Like, I could put my laptop into a furnace and melt it into slag. Now it will have no features, and that will make it very secure!
They didn't "strip" anything, they've split it into 2 variants, a package without networking features (-DWITH_XC_NETWORKING=OFF) and a package with them, because it's considered a privacy issue to have your password manager phone home and fetch favicons and so on. The packages will be called keepassxc and keepassxc-full going forward.
I expect the KeepassXC people are mostly bothered by the naming of the package because the version called "keepassxc" is now the basic one. Anyway, the maintainer has offered to call them -minimal and -full and to make "keepassxc" a metapackage that pops up a debconf dialog telling users that install it to choose one. There is precedent with other complex packages that are split into basic and full. This should solve things nicely for everyone.
Afaiu it, he added a second package with (quote) "all the crap" later, after the storm.
And no, it wasn't just the favicons feature that was removed (which like ... is that really such a big privacy issue that you need to remove it from the binary?). Support for Yubikey was removed as well — which is not a privacy issue. The reasoning mentioned by the Debian maintainer is that all of these features might turn out to be security issues in the long run. Thus, in his view, a password manager application must do nothing but provide access to the database within the app.
I find it an interesting example of diverging upstream, maintainer, and user interests in any case.
I find it a lot of unnecessary fuss over unstable. Sid is supposed to make breaking changes, you offer feedback and you follow it through politely. The next Debian stable is one year away, this is not an urgent matter
And no, it wasn’t just the favicons feature that was removed (which like … is that really such a big privacy issue that you need to remove it from the binary?)
Fetching a favicon means raising a network connection with a predictable endpoint. That's already three concerns (four on the modern internet) to handle security-wise, and it's absolutely an unneeded feature. Favicons could just be shipped on something like keepassxc-data or keepassxc-contrib to handle locally, no need to raise a network call.
I highly recommend reading the Github thread as this is not at all an accurate representation. These features you're talking about are off by default. Removing them from the existing package is just breaking existing users. There's already a report from a user who can't access their passwords because yubikey support was suddenly removed. You don't do that to users just because you suddenly develop an opinion as a package maintainer that you feel is important. There was no dialogue, no consideration and a very rude, dismissive attitude of Julian.
Ah, I was wondering why I couldn't get it to detect my yubikey. I saw keepassxc-full in the repo but that also didn't seem to work. I'll have to revisit it.
I've never heard of either of these things and I've been in the community for decades, cheers.
I only use Plank itself, not dash-to-x anything. I've no idea what that even means tbh as I'm an i3 user usually so I've been out of the GNOME game for a bit.
learn how to use the command line. spend a week or so getting used to doing file operations like moving, copying, extracting, etc on the CLI to get a feel for it.
Dash-to-Plank specifically says it does not support Wayland. Plank has had an issue open about Wayland support since 2016, and they still haven't done it. Can't blame Wayland.
What's your use case for Plank? My guess is you're using GNOME wrong.
I don't blame Lemmy even though the official instance (and therefore devs) is kinda sus. They even delete discriminatory comments that I report quite quickly. The thing is that I see toxic comments all the time and what surprises me is that often they're replies to non-provoking and absolutely reasonable posts/comments (this case is not anywhere near the worst I've seen). That means the people behind them are just very aggressive which still hurts me a lot even though I lost hope for humanity quite some time ago. I guess I see a bit more % of them in the wild than you do for some reason
Linux
Hot
This magazine is not receiving updates (last activity 51 day(s) ago).