There is no "IPv8". Any crackpot can submit an internet-draft to the IETF, and this person happened to call theirs IPv8. If the submitter actually read the draft rather than feeding it to the slop cannon, they would have realized it is also a LLM hallucination that someone uploaded to IETF.
I am fairly sure the authors do understand this (see: "Most network engineers would laugh this off as an April Fools RFC written by an enterprise architect on buzzword overdrive."). But since the proposal got a lot of attention, responding to it is a public service. And delegating this to an LLM arguably provides an accurate signal as to how much human attention the original proposal deserved :-P
This. While I'm generally opposed to using LLMs to make changes in critical parts of systems, a vibed spec just naturally prompts a vibed implementation.
In fairness, they exist by virtue of having working implementations that (at least a few) people actually use, not by virtue of being an Internet-Draft.
There was also a second prior "IPv8" proposal from a couple years later by notorious mailing list troll Jim Fleming, which he subsequently expanded to "IPv16"
The entire point of the experiment was to take this specific, absurd Internet-Draft (which indeed exists as an active submission) and see what happens if someone actually implements it to the letter instead of just hand-waving it away.
LLMs might be able to hallucinate RFC text, but they certainly can't compile a patched Linux 6.6 kernel with a working AF_INET8 socket family, patch musl/iproute2/frr, spawn a 10-node QEMU mesh, and route 112,000 active FIB entries under live traffic.
The source code and commit history are right there in the GitLab repos - feel free to pull the kernel tree and run the test suite yourself.
It's not JPEG like at all, unlike JPEG it is using the DCT only for the loss function, so it can have frequency weights, having the same approximate effect as JPEG's quantization matrices (at least, according to the slopped-out description). Whether that actually improves things for this type of content is unclear.
Yes and no. There is sharing of RAM with IGPs from AMD and Intel, but my understanding is the way Microsoft handles the RAM sharing isn't quite as 'unified' as with MacOS. It's not a difference in hardware really, but a software implementation. Also, when we're talking about older Intel/AMD IGP solutions, the graphics cards paired really couldn't take advantage of larger amounts of RAM.
Something like the new Strix Halo stuff from AMD is actually useful with larger amounts of RAM, and basically is the same as the Apple architecture.
Yes. The default ffmpeg build enables everything, and most distros follow suit. Security conscious web services generally disable a lot of them, but there is no official list on which are considered more secure than others, so every site tends to have its own unique mix.
Sure, but there are a lot of media applicances that don't really have upgradeable software. I suppose it can be pretty useful to just (un)wrap MoQ and feed the result over a local interface into something that just expects M2TS and vice versa.
The nice thing about fMP4 is that it's supported by both HLS and MPEG-DASH, so you can save yourself the effort of duplicating all data at the CDN level (or using a CDN that can just-in-time assemble fMP4 and M2TS files from the same underlying source).
Awesome! I might try it again, tbh I have KDE on one computer but I don't use it much as my muscle memory is very gnomy and I haven't taken the time to tried to switch back in long term and I admit until hearing about that very little strong incentive to do so.
The engineer on the truck seemed to have the most annoyance with the PTP aspect of 2110, but it seemed nobody questioned the move to 2110, and at least as far as broadcast equipment goes, they're all in on 2110. As a small(ish) YouTuber, NDI is more exciting to me, but I'm not mixing dozens or hundreds of sources for a real time production, and can just re-record if I get a sync issue over the network.
Perfect is the enemy of the good, as always—reading through that site, it seems like no solution is perfect, and the main tradeoff from that authors perspective is bandwidth requirements for UHD.
It looks like most places are only hitting 1080p still, however. And the truck I was looking at could do 1080, but runs the NHL games at 720p.
> it seems like no solution is perfect, and the main tradeoff from that authors perspective is bandwidth requirements for UHD.
The “no standalone switch can give enough bandwidth” issue has generally been solved since that page was written. You can buy 1U switches now off-the-shelf with 160x100G (breaking out from 32x800G). One of the main drivers of IP in this space is that you can just, like, get an Ethernet switch (and scale up in normal Ethernet ways) instead of having to buy super-expensive 12G-SDI routers that have hard upper limits on number of ins/outs.
Of course, most random YouTubers are not going to need this. But they also are not in the market for broadcast trucks.
Yes its a huge benefit. Of course without an NMOS SDN solution, actually reliably routing so much data over a network (especially if incrementally designed) is a huge pain in the ass. But thankfully we have those systems now.
We sort of traded the big expensive SDI switchers for big expensive SDNs
Also, I guess we traded a ton of coax cable for somewhat more manageable single-mode fiber. :-)
I never fully understood why SDI over fiber remains so niche, e.g. UHD people would rather do four chunky 3G-SDI cables instead of a much cheaper and easier-to-handle fiber cable (when the standards very much do exist). But once your signal is IP, then of course fiber is everywhere and readily available, so there seems to be no real blocker there.
I don't know but is there a maximum compression weight on fiber, because in some of these broadcast centers they've got cable trays of SDI that are so heavy and packed that removing a dead line is a fire hazard (because the friction of pulling the line could cause a fire).
They'd obviously need a lot less and the lines are a lot lighter but maybe folks figured if they could avoid repeating that scenario in their design, it might be a good idea :-P
You can build fiber basically arbitrarily solid. A normal patch cable won't be that solid, but the more rugged trunk cables is something like (just pulling out of a data sheet for something I used a while back):
* Outer diameter: 6mm
* Max tensile load: 900 N
* Crush resistance: 750 N / 10 cm
* Max proof stress: >= 0,69 GPa
To be clear, this is not specially rugged cable by any means. This is just a normal G12 cable for general use. You can get stuff that's much more solid. It's certainly much lighter than the equivalent SDI copper cable.
2110 is certainly popular in the industry. There’s no one way to get video out of a sports venue and across the network to takers, though. Where I work different workflows have SDI, NDI, SRT, RIST, and our own internal stuff uses MPEG TS over UDP and gets routed by a distributed system that determines next-hop routing through our network at each hop. The encoding might be H.264, HVEC, or even JPEG2000.
NDI is indeed quite good for prosumer cases. As a Newtek (now Vizrt) shop, our Tricasters speak it natively and that's a great reason we've made use of it.
That being said, if you aren't already in the Newtek/Vizrt ecosystem, might I recommend exploring Teleport, which is a free and open source NDI alternative built into OBS which has also served us very well.
