I agree that, theoretically speaking, YouTube might be protecting some end users from this type of attack. However, the main reason YouTube re-encodes video is to reduce (their) bandwidth usage. I think it’s very kind towards YouTube to view this as a free service to the general public, when it’s mostly a cost-cutting measure.

Good point, though I believe you have to explicitly enable AV1 in Firefox for it to advertise AV1 support. YouTube on Firefox should fall back to VP9 by default (which is supported by a lot more accelerators), so not being able to decode AV1 shouldn’t be a problem for most Firefox-users (and by extension most lemmy users, I assume).

About the “much higher CPU usage”: I’d recommend checking that hardware decoding is working correctly on your device, as that should ensure that even 4K content barely hits your CPU.

About the “less sharper image”: this depends on your downscaler, but a proper downscaler shouldn’t make higher-resolution content any more blurry than the lower-resolution version. I do believe integer scaling (eg. 4K -> 1080p) is a lot less dependant on having a proper downscaler, so consider bumping the resolution up even further if the video, your internet, and your client allow it.

I believe YouTube always re-encodes the video, so the video will contain (extra) compression artefacts even if you’re watching at the original resolution. However, I also believe YouTube’s exact compression parameters aren’t public, so I don’t believe anyone outside of YouTube itself knows for sure which videos are compressed in which ways.

What I do know is that different content also compresses in different ways, simply because the video can be easier/harder to compress. IIRC, shows like last week tonight (mostly static camera looking at a host) are way easier to compress than higher paced content, which (depending on previously mentioned unknown parameters) could have a large impact on the amount of artefacts. This makes it more difficult to compare different video’s uploaded at their different resolutions.

Unless your initial recordings were lossless (they probably weren’t), recompressing the files with a lossless flag will only increase the size by a lot. Lossless video is HUGE, which is why almost no one actually records/saves it. What you’re probably looking for is visually lossless transcoding, where you do lose some data, but the difference is too small for most people to notice.

My recommendations:

1. Go to your recording software and change the setting to better compress your videos the first time around. Compressing once generally gives a better quality to size ratio than compressing twice. It’s therefore best if your recording software get it right first time, without you having to keep on recompressing your videos.
2. When tinkering with encoding setting, trying to find what works best for you, it might be useful to install Identity to help you compare the original files and one or more transcoded version(s).
3. Don’t try to recompress the audio; you’ll save very little space, and the losses in quality become perceptible much faster than video. When using ffmpeg, the “-c:a copy” flag should simply copy the original audio to the new file, without any change in quality or size
4. I’d recommend taking some time to read through the ffmpeg encoding guides. H265 and AV1 are good for personal archiving, with AV1 providing better compression ratios at the cost of much slower encoding. You could also choose VP9, which is similar in compression ratio and encoding speed to h265.
5. You’ll have to choose between hardware and software encoding. Hardware encoding can (depending on your specific hardware and settings) be 10-100x faster than software, but software generally gives better compression ratios at similar qualities. You should test this difference for yourself and see if the extra time is worth it for the extra quality. Do keep in mind that AV1 hardware encoding is only supported by some of the most recent GPU’s (rx7000 and rtx4000 from the top of my head). If you don’t have one of those GPU’s, you’ll either have to choose software encoding or pick a different codec.

Not to be an unfunny nitpicker (I don’t know why I’m denying this, that kinda the whole point), but all iphones do have lossless audio streaming via AirPlay. I’m assuming that you specifically meant Bluetooth streaming, but then you should’ve said so. Furthermore, normal aptx isn’t high resolution, only aptx HD and aptx adaptive are. The phone does support aptx HD as well, but once again, you could’ve said so from the start (though 3 characters more or less might make a significant difference to most memes, this one certainly wouldn’t have had that problem)

Luxury! My homeserver has an i5 3470 with 6GB or RAM (yes, it’s a cursed 4+2 setup)! </badMontyPythonReference>

Interesting, I also run Nextcloud and pihole, and vaultwarden, jellyfin, paperless-ngx, gitea, vscode-server and a minecraft server (every now and then).

You’re right that such a system really does show its age, but only when doing multiple intensive tasks at the same time. I try not to backup my photos to Nextcloud while running minecraft, for example, as the imagine identification task pins my CPU at 100%. So yes, I agree, you’re probably not doing anything out of the ordinary on your setup.

The point I was trying to make still stands though, as that pi 2B could run more than I would’ve expected beforehand. I believe it once even ran jellyfin, a simple file server, samba, and a webserver with a simple HTML website. Jellyfin worked just fine, as long as the pi didn’t have to transcode (never got hardware transcoding to work).

It is funny that you should run out of memory, seeing as everything fits (albeit, just barely) on my machine in 1/5 the memory. Would de overhead of running VM’s account for such a large difference?

Coming from someone who started selfhosting on a pi 2B (similar-ish specs), you’d be surprised. If you don’t need anything fast or fancy, that 1GB will go a long way, and plenty of selfhosted apps require very little CPU. The only real problem I faced was that all HTTPS-related network tasks were limited at ~3MB/s, as that is how fast my pi could encrypt the data (presumably, I just saw my webserver utilising the entire CPU and figured this was the most likely explanation)

It depends what you’re optimising for. If you want a single (relatively small) download to be available on your HDD as fast as possible, then your current setup might be better (optimising for lower latency). However, if you want to be maxing out your internet speeds at all time and increase your HDD speeds by making the copy sequential (optimising for throughput), then the setup with the catch drive will be better. Keep in mind that a HDD’s sequential write performance is significantly higher than its random write performance, so copying a large file in one go will be faster than copying a whole bunch of random chunks in a random order (like torrents do). You can check the difference for yourself by doing a disk benchmark and comparing the sequential vs random writes of your drive.

qBittorrent has exactly the option you’re looking for, I believe it’s called “incomplete download path” in the settings, letting you store incomplete downloads at a temporary path and moving them to their regular location when the download finishes. Aside from the download speed improvement, this will also lead to less fragmentation on your HDD (which might be part of the reason why it is so slow when downloading directly to it). Pre-allocating space could have the same effect, but I would recommend only using one of these two solutions at once (pre-allocating space on your SSD would only waste space)

“cis” and “trans” are prefixes denoting on what “side” something is. “cis” means “on this/our side”, while “trans” refers to “the other side”, for example:

1. “Cisalpina” is how the Romans referred to their side of the Alps (modern day Italy), while “Transalpina” referred to land on the other side of the alps.
2. There exist certain pairs of molecules with either a “cis” or “trans” prefix, depending on whether certain identical groups are on the same side or on opposite sides, respectively.

The modern use of “cis” and “trans” is generally about gender. A cisgender person is someone whose gender identity aligns with their sex assigned at birth, while a transgender person is someone for whom that doesn’t hold true.

In this meme, the person on the right is wearing a transgender flag for a shirt, and presumably offending the cisgender person on the left by calling them cis. The meme is making fun of the fact that some cisgender people consider “cis” an insult, when it really only is a neutral and non-offensive description.

Which compression level are you using? My old server is able to compress flac’s at the highest (and therefore “slowest”) compression level at >50x speed, so bumping the level up shouldn’t be too hard on your CPU.

I’ve been running some external drives on my server for about a year now. In my experience, hard drives with an external power supply suffer less from random disconnects. The specific PC also makes quite a large difference in reliability. My server is just a regular desktop and has very little problem staying connected and powering my 3 external drives. My seedbox is an old laptop, and has been having almost constant problems with random disconnects and power issues. Maybe test how well your framework does with some external drives before committing to the plan?

I believe SSD’s don’t actually experience wear when reading data, only when writing. Loading more data from SSD’s shouldn’t cause any premature failure. Overwriting more data each update could cause the drive to fail slightly earlier, but if that’s really that big of a concern, you’d be best of moving to Debian stable (no updates means no SSD writes).

If SSD wear prevention is really that big of a concern, you might be interested in profile-sync-daemon (https://wiki.archlinux.org/title/Profile-sync-daemon). It reduces writes to hard drives by keeping your browser profile in RAM, and only periodically syncing it to disk.

Though I must add that SSD’s wearing out really isn’t that much of an issue with modern drives. With normal usage, a drive will become obsolete long before it actually wears out.

I tried using Linux alternatives to iTunes, but it was always a pain. Even iTunes itself on a separate windows box was more of a hassle than I wanted. I eventually discovered rockbox, which works great with my iPod (5th gen AKA video): it has way more config options and allows me to simply create .m3u playlists and use my own folder structure. If your iPod is supported (https://www.rockbox.org/wiki/IpodPort.html), I’d absolutely recommend Rockbox over other solutions.

If your iPod isn’t supported by Rockbox (like my nano 5th gen), you could probably use strawberry or GTKpod. Both are imperfect, but work “good enough”.

Not OP (OC? Not the person you were helping, you get what I mean), are you sure you meant df -h? fd -H seems more useful for to me when trying to find a specific file in a dotfolder, though even that didn’t work on my system. fd ignores ~/.config by default, so you need to use fd -u (which is an alias for fd -I -H) to find the correct files.

Anyways, from your description it seems like the correct file would be ~/.config/kwinrc, which exists on my system.

You could look at the awesome-selfhosted list, specifically these two sections:

https://awesome-selfhosted.net/tags/recipe-management.html

https://awesome-selfhosted.net/tags/task-management--to-do-lists.html

I don’t have any experience with any of those, but there might be something that fits your needs.

Ah, it looks like we have a small misunderstanding. I thought you were talking about uncompressed video, which is enormous. This is only used in HDMI cables for example. A 1080p60 uncompressed video is 2.98Gbit/s, or about 1.22 terabytes per hour.

A remux is “uncompressed” in the sense that it isn’t recompressed, or in this case transcoded. A remux is still compressed, just to a lesser degree than a transcode. This means the files are indeed larger, but the quality is also better than transcodes.

To clarify the article’s confusing statement: they claim that remuxes can reduce size by throwing away some audio streams, while keeping the original video. This is true, but the video itself hasn’t gotten any smaller: you are simply throwing away other information.

Remuxes aren’t uncompressed, nor are they losslessly compressed. They’re just a 1:1 direct copy from some other medium (generally blu-rays or DVD’s).

Except safari of course (almost 20% market share).

Also, there are plenty of other browsers using Mozilla’s gecko engine. A quote from Wikipedia: “ Other web browsers using Gecko include GNU IceCat, Waterfox, K-Meleon, Lunascape, Portable Firefox, Conkeror, Classilla, TenFourFox.” (https://en.m.wikipedia.org/wiki/Gecko_(software))