Timing and scalability are probably the biggest issues with realtime P2P applications. Scalability is becoming a bit less of an issue; with mid-splits becoming the norm on cable internet services and 5G SA rolling out, there's just a lot more bandwidth to go around.

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.

Many opioids, including opiates, used to be OTC. I personally know someone who used to smoke paregoric (camphorated tincture of opium), which was OTC in the US until 1970.

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

Some of us are already doing this. My main phone is a Google Pixel 8 running LineageOS 23.2 with F-Droid, microG, and Aurora Store installed.

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.

>For things requiring Play Integrity, I picked up a $20 burner carrier-locked Motorola phone at Walmart for $30.`

So it's a $30 burner phone, not $20?

Doesn't matter, it's still just $40.

I forget if it was $20 or $29.99, but in either event, it wasn't much. If you shop at Wally World regularly, you can sometimes find carrier burner phones for $10-$20, but finding them in-stock can be a bit of a challenge.

Hopefully they exempt UDP traffic with a destination port of 53. Or suspiciously-large ICMP echo request and echo response packets.

Systems like Everseen make that approach significantly riskier than it used to be. A live video of you checking out is run through image classification software, so if you scan a steak as 4011, it'll pause the checkout flow and call the SCO (self-checkout) attendant to watch the video of you scanning the item. They then have to approve the scan, at best leaving you publicly humiliated.

One of the AP (asset protection) guys at my local store always wore an eyepatch and a t-shirt reading "A bullet a day keeps the terrorists away". He did NOT look like a typical grocery store employee, and I'm sure that was intentional.

I used dvgrab to ingest my old tapes, and ffmpeg and avisynth/QTGMC to de-interface and encode files for easy viewing (though I keep the original .dv 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.

Just because I've dealt with this exact issue in the past, it may have been a 30fps vs 29.97fps issue. For me the audio was a fixed length, but the frame rate was SLIGHTLY too fast. The problem can manifest as either too slow or too fast depending on which side is expecting 30fps vs 29.97fps.

I think it was just clock drift on the camcorder during the initial recording, as I'm pretty sure I tried adjusting the frequency of the audio track to make it the same duration as the video track, and the A/V sync was still wrong.

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.

This is very likely it

Transcode to another format first that keeps the timecode?

Ffmpeg's dvvideo implantation is unfortunately just broken and mangles timecodes, even if just doing a stream copy from dvvideo to dvvideo without any re-encoding.

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.

I would recommend VyOS Stream for this situation. It has better performance and hardware compatibility than *BSD-based software routers, and it also has a nice CLI that is syntactically similar to Vyatta and EdgeOS (found on Ubiquiti's Edgerouter line).

In additon, compared to PF/OPNsense or OpenWRT (Linux based), you have more control and exposure to the underlying network concepts with VyOS. You're not configuring the kernel manually, but you still learn quite a bit.

I fully agree. Similar to killing bacteria with antibiotics, Attempting to idiot-proof machinery only leads to the creation of idiot-proofing-resistant idiots.

We need to move back to putting users back into full control. Machines (including computers) should ALWAYS respect the input of the user, even if the user is wrong.

If a person shoots themself with a gun as a result of their incompetence, we don't fault the gun manufacturer for not designing the gun to prevent auto-execution. If you can't operate a firearm safely, you shouldn't attempt to operate a firearm.

Similarly, if a person deliberately points their car a solid object and accelerates into it, the actions of the operator shouldn't be the car manufacturer's responsibility. We need to get rid of ESC, ABS, AEB, etc. These features have created a whole slew of drivers who speed headfirst into the back of stationary drivers and expect their car to stop itself. This works right up until a sensor fails and the operator flies through the windshield (usually people like this don't wear seat-belts). If you can't drive, you shouldn't be driving until you rectify your incompetence.

Similarly, phones and computers should respect user input. If a users wants root access to their personal device, they should be able to get root access. If a user runs "rm -rf --no-preserve-root /" as root, the device should oblige and delete everything, since that is what the operator instructed it to do. If you can't be trusted to use a computer, you shouldn't be using a computer until you rectify your incompetence.

The lack of accountability in modern society is disgusting, and it leads to much deeper societal problems when people refuse to better themselves and instead expect the world to shield them from their willful ignorance.

I was with you right up until "We need to get rid of ESC, ABS, AEB, etc.".

That is unreasonable. ABS, ESC, and AEB all exist to interpret what the driver intends. The driver does not intend for their wheels to lock up, that's why ABS exists, nor does the driver intend to skid. You can argue that AEB does not reflect the will of the driver, but it can also be disabled.

I was admittedly a bit hot-headed when I wrote the original comment, but the critical qualifier in all of this is that these driver assist technologies should be optional and easily disable-able in a persistent manner, with a dashboard warning light to remind you that they're disabled.

In a lot of modern cars, there's no straightforward way of fully disabling ABS, traction control, electronic stability control, etc. There are certainly situations where they may be helpful, such as in a top-heavy truck with an open differential, but ABS and traction control systems can pose problems in other situations, such as in snow. Especially in the case of RWD coupes with limited-slip differentials, a bit of skidding may be an asset, provided the driver knows how to correct for oversteer. Even in FWD cars, ABS can sometimes be a detriment when stopping in snow, as the rapid automated brake-pumping can dislodge the snow you were otherwise going to be holding steady on.

Ultimately, I'm opposed to driver assist features being forced onto drivers who don't want to use them. I'm also opposed to teaching people how to drive with these assistance features. It's a lot like teaching students to use AI chatbots to do their work instead of teaching them to do their work themselves.