neo [he/him]
  • 1 Post
  • 6 Comments
Joined 4Y ago
cake
Cake day: Jul 25, 2020

help-circle
rss

Yeah. I think I’ll end up having to do platform-specific ifdefs with either pthreads or threads.h, so I guess I may as well use the much better established pthreads and get macOS support by default. In fact, I just now learned that even glibc didn’t support C11 threads until 2018, according to this https://sourceware.org/bugzilla/show_bug.cgi?id=14092#c10


Was my decision to use C threads unwise?
Without realizing what I was getting myself into, I wrote some code using C11's `threads.h` (EDIT: every time I use the angle brackets `<` and `>` they just get eaten, even in the code snippet block.) I'm realizing after the fact that this is basically only supported on Linux (gcc/clang). This is my target platform, but I guess if I could cross compile to Windows or macOS that would be nice, too. C's threads nominally appear to be a great feature. Finally, a standardized and straightforward interface to threads that would be cross-platform compatible. The reality appears to be anything but. So is it worth just replacing that code with pthreads? Is there some near-term development on C threads that might make this worthwhile to use? I'm kind of surprised it hasn't really caught on some 12 years after the standard was introduced.
fedilink

Depending on what I’m encoding, I am trying as much as possible to do AV1 + Opus.

x264 kind of stands on its own. It is a legendary encoder with excellent encode times, but h264 is an ancient codec and it really shows if you don’t give it a bitrate that’s, frankly, too high. I use it most frequently these days for sharing short, low res clips of videos on Discord or through iMessage or something.

So that leaves us with with our modern choices: hevc, vp9, and AV1.
Off the bat I would say VP9 is irrelevant just because it’s way too slow to encode, and is effectively superseded by AV1. To whatever extent possible I try to use AV1, reencode into AV1, download AV1, and so forth. When done correctly it will shrink files even smaller than hevc can, it can encode relatively quickly with SVT-AV1 and is patent unencumbered so it’s actually supported in web browsers. If the video is an AV1 .webm it will play in Firefox. If I need subtitles, I can put them in a .mkv.

HEVC (with x265) is a pretty strong choice. I will not avoid downloading torrents in this format but I will avoid encoding into it. It maybe has better compatibility in certain cases, like if you have a “smart” TV (ugh) that can natively decode it. In which case that might override any decision you will make: you just want the best compatibility with your existing hardware.

As for audio, that’s Opus. Every time. It absolutely whips. For stereo audio I can do Opus at 96 or 112kbps and it is transparent. Another source with more going on (maybe loud explosions and effects and all that) could possibly benefit from 128. It’s great.

The final thing to mention about encoding is no matter which codec you use you will have to learn a bit about how to use it. You can one and done the encoders with default choices, but at minimum you do need to factor in what happens when you do things like change preset speeds. From there you can consider things like what about changing the keyframe interval (for shorter vids I will do more frequent keyframes to make seeking tolerable. For something like a full movie a keyframe every 10 seconds is probably fine. But what about scene detection? What about bit depth?). Potentially much to consider.


Many times that’s true, too. One of the saddest things in torrents is seeing two torrents with identical contents that were created separately, or one just recreated so someone can add their website to it or something, thereby dividing the pool of possible peers.

I think one of the most interesting ideas in BitTorrent v2 is that hash trees are formed per-file, not per-torrent. So two torrents with identical contents could, if I understand this right, basically be considered one and the same. It would be cool to see more wide adoption and promotion of BT v2 https://blog.libtorrent.org/2020/09/bittorrent-v2/


So by chance I was in university and invited into what by my roommate. I literally bought more internet bandwidth from my uni to handle an early freeleech event where I got to mega game the system (By accident! I didn’t really know what I was doing. And good thing it was a private tracker because I was on a bare connection. I didn’t know what A VPN was at that time, much less how to hide my identity online).

I thought my ratio was totally unfair so I never really abused it, but that’s kinda the problem. Only by chance I had like a 500 ratio, whereas someone like you had no chance ever to catch up to the earlier established players. Even though I wasn’t a victim of the ratio, the concept of your story is just another reason why I dislike private trackers.

That said, the best thing about what.cd was just how well organized and categorized it was. Library of Alexandria style shit, now lost to us. Plus the forums with some real music-heads were great, too, and you could really expand your music horizons by talking with those people. I liked that it was NOT a Reddit-style forum, so when something new dropped everyone had a say. Upvotes didn’t influence that kind of conversation. At any rate, I stopped pirating music so much maybe beginning in 2013 or 2014, but every time I look now the uploads are either 320kbps (overkill bitrate, garbage ancient codec) or FLAC (nice for archiving, but not what I want). So I end up DLing FLACs and then converting them into 128kbps Opus. It works, but my music horizons aren’t broadened without that what community. I guess all I mean is I don’t miss the private nature of what, but I do miss the community.


I prefer public trackers and torrents just because I don’t like gatekeeping piracy. I want those bits to be distributed as far and wide as possible. So anything I get and/or seed will be public.

Even if there are bad peers that don’t give back (which there are many), plenty enough times it’s just people with shitty under served Internet connections. I’m fortunate enough to have a good enough connection where that doesn’t bother me.


Rust is a great language but it really has a lot of up-front costs. Whether you are learning it for the first time, or starting a new project, both. Python is always going to be faster “from idea to deployment.”

I think like the other person said, start with the Rust book. It really is a perfectly good introduction. But what I think you’ll find is if you want to be productive with Rust you will need to get the ground rules down or else you will be constantly tripping on the borrow checker and ownership rules. If you think you are getting somewhere with the book, try rewriting something you’ve done in Python. If that works out, great! If not, it’s OK to accept that Rust might not be worth your time.