Containers are nice, but they're not strictly necessary. On Google Pixel 6 and newer phones, you can take it a step further and root your phone and run a KVM-accellerated arm64 Linux virtual machine on your phone. There's a port of Limbo PC emulator that includes support for the KVM accelleration, and it works quite well! It even allows you to pass through USB devices to the guest.

Old Optiplex are also good deals. I bought a Dell Optiplex 5070 MT for $150 for myself and 2 Dell Optiplex 3070 SFF computers for $75 each to replace my mom's aging Windows 7 PC. All 3 computers take DDR4 and M.2 NVMe SSDs and have an Intel i5-9500 CPU that will also run Windows 11 pretty well, if you're into masochism that is.

Termux is only slower without root if you use proot. PRoot provides a limited implementation of chroot that runs unprivileged in userspace, but this also causes it to be pretty slow. If the server software you want to run is available in the Termux repos, you can use that and have it run at full-speed.

Termux works by patching all programs to treat /data/data/com.termux/files/usr as the root directory and /data/data/com.termux/files/home as the home directory. This introduces some compatibility issues, but it doesn't make it any slower.

The Termux project has a great wiki at https://wiki.termux.com/

RFK Jr. is an anti-vax crackpot, but Hep C isn't vaccine-preventable. On the other hand, we can absolutely blame RFK Jr. for our rising Hep A, B, and D rates.

Timing issues can be worked around and GPS modules are cheap.

NAT problems aren't usually that bad. Only a minority of networks use symmetric NAT implementations, with most seeming to be using port-restricted cone NAT (EIM/APDF), which can still communicate with any other NAT implementation using endpoint-independent mapping (EIM). Most CGNAT implementations that I've encountered use EIM, with some also doing endpoint-independent filtering (EIF). Between UDP hole-punching, UPnP, NAT-PMP, and IPv6, it's usually possible to establish a P2P connection between 2 endpoints.

A game could use a hybrid client/server and P2P model, with the option to run entirely P2P while accepting its limitations.

I believe 1970 was also the year when amphetamine (Benzedrine) inhalers stopped being OTC.

For things requiring Play Integrity, I picked up a $20 burner carrier-locked Motorola phone at Walmart for $30. It's WiFi-only, given that I'm never going to pay for service on it, but I can also tether it to my main phone. It's also useful for writing one-star reviews on apps that require Play Integrity to function, which is something everyone should be doing.

I'm so glad the audio and video tracks are stored interleaved, as it made my solution possible, and the results I got were great. By splitting the interleaved video into small enough chunks, padding the audio, and cutting it exactly to video length, the padding was practically imperceptible.

The only issue I ran into was that ffmpeg can't cut audio with any real precision. I eventually figured out that I could dump the audio track to a headerless PCM file, calculate the exact byte offsets for my cut points, and cut them with perfect precision using the head and tail commands from GNU coreutils. This was perfect because I was able to use the cat command to combine all of the padded audio chunks into a single raw PCM file, which I then made an AAC encode of with ffmpeg to mux with my original encoded video track.

Fortunately, dvgrab does allow you to take the original .dv file and generate a .srt subtitle track with time stamps that you can mux into your encoded files.

The biggest issue I ran into was that while the audio and video were properly synced up in the original .dv file (due to it being an interleaved format), when I re-encoded the videos, the audio and video would drift out of sync as the video went on.

I was able to fix the sync issues by using dvgrab to split the original dv file into a bunch of 3 minute chunks. I then wrote a script to extract the audio track from each chunk, pad the end of the audio with milliseconds of silence to the exact length of the video track, combine the padded audio tracks, encodes the combined track, and muxes the fixed audio track with the encoded video. This worked really well; the silence padding is imperceptible, but the audio and video are still in sync - even after 2 hours.

A final point that needs making is that doing anything with dv files in ffmpeg (even -c:v copy) destroys the SMPTE timecodes embedded in the original file, making it much harder to split by scene.