> They didn't modify anything other than the build, to exclude certain dependencies.
To be clear here: They do modify it further than that by applying a number of patches.
For example, they replace libx264 with OpenH264 which also requires some changes to the UI code since it is (unfortunately) hardcoded to expect x264 to exist. While there have been efforts to upstream those changes, they have not yet been merged.
The mdat box does not have a defined structure, and the specification actually states that attempting to define a structure is almost certainly a mistake. In order to find the data the player is looking for it has to read the moov box, which contains the byte offsets and sizes of "chunks" of data. Since there is no requirement for chunks to be contiguous, or even in the same file, we can simply skip over the fragmentation-related boxes within the data box.
> Having recently written my own fragmented-MP4 remuxing library, I felt this pain too, and my soon-to-be-published writeup has very similar things to say about the ISO's paywalling practices.
Would be curious to hear what goals you had with writing a muxer yourself as well, given that most people just use LibAV/GStreamer/GPAC and call it a day.
> I think one of the hardest parts of ISO-BMFF, aside from spec availability, is that it's pretty hard to implement "cleanly", making existing code confusing to use as reference. (My own implementation is certainly not clean either)
I certainly wouldn't call the OBS implementation "clean" either. It's very much inspired by the FFmpeg/LibAV implementation since that one is fairly straightforward (not a lot of abstraction), and gets the job done (and also is GPL/LGPL so not a huge concern looking at it).
The short answer is, it's for an exploit. It involves some slightly less-well-trodden boxes, and adding specially crafted metadata to live-generated videos in real-time, which existing libraries couldn't help me with much (and I did spend some time fighting a few libraries, but couldn't make them do precisely what I wanted).
"Library" is perhaps an overstatement, it does the things I need and not much more.
> Also am I stupid for buying a switch instead of emulating it?
No, while the emulation is pretty good, it's not perfect, and new titles won't always run out of the box. And things like online multiplayer naturally don't work. A Switch is a guaranteed-to-work way to play those titles, and arguably more convenient if you actually use the portability of it.
There are of course non-piracy ways to use them. I own a hackable Switch and have dumped the games I purchased so I can play them in an emulator on my Steam Deck. But not every title will run perfectly that way, so sometimes the Switch is the only portable way of actually playing them.
Online technically works on yuzu - it emulates the same capabilities as switches connected to each others locally. This doesn't mean there are no issues. A PC and a Steam Deck running Mario Kart will have desync issues due to the Deck not hitting 60fps 100% of the time resulting in a quick connection loss.
It doesn't, that's a different feature called LAN play.
LAN play mostly exists to be able to reliably connect Switches to each other at tournaments and such (which is why you find it more frequently in competitive games). It doesn't connect to Nintendo's servers, it just looks for other devices on the same network for local play purposes. Its not the same thing as regular local multiplayer, that's a different feature.
You can somewhat trivially intercept this using DNS if you want to do long-distance co-op, but it's absurdly jank from my experience.
Also both Ryujinx and Yuzu support connecting with LDN_mitm which well, man-in-the-middles the LDN sysmodule on hacked Switch devices to enable the same thing as LAN play interception but then for titles that don't support LAN play.
MoQ (Media over QUIC) development is underway at the IETF - with involvement from Twitch/YouTube/Facebook/Cisco/etc. - but will probably still take quite some time before its finalised and can be adopted.
How many of those users are direct vs. relaying through a TURN server? I'm genuinely curious, as I kind of anticipate that the majority of users are relaying, but I guess if p2p requests can open router ports in the common config, that could work.
IPv6 users usually manage a direct connection, and that is ~half the world now.
IPv4 users seem to manage a connection ~70% of the time in my experience. Remember only one peer needs to have a router with a suitable config for everything to work.
When a PR sits for many months and has hundreds of comments, it probably means it's getting near to bikeshed territory and it would have been better to get small PR's in adding the groundwork and a project plan agreed with leads beforehand...
I tried to keep the size as small as I could. It is just basic audio+video (no Simulcast/ICE Renegotiation etc...) It has been a tough process, but I am going to keep working on it until I can get consensus.
1. It looks like RTMP didn't support it, and arguably still doesn't, since they link to an "enhanced RTMP" spec.
2. "Unlike some other protocols that only support specific video and audio formats, SRT does not limit you to a specific container or codec, since it is media or content agnostic. SRT operates at the network transport level, acting as a wrapper around your content. This means it can transport any type of codec, resolution or frame rate. This is important because it can future proof workflows by working transparently with MPEG-2, H.264, and HEVC for example."
1. Yes, it's an extension to the spec published by an organisation Adobe and Google are a part of. It extends the protocol in a backwards-compatible way.
2. SRT, in practice, is only ever used with MPEG-TS as the container for audio/video data, which does not support AV1.
The point is, you don't even need to extend the protocol for SRT. You just need to set up servers that are ready, just like companies are in the middle of doing for other techs.
Which I'm sure is still significant work, but is it much harder to do with SRT?
The "just" is doing a lot of work here. Extending existing RTMP infrastructure is obviously much easier than spinning up an entirely different one. And you'd still have specify a way to use anything but MPEG-TS to send audio/video over SRT, which de facto does not exist (at least not that I can find).
I agree that extending RTMP isn't ideal, but other solutions have their own set of limitations, problems, and challenges. Whether that's SRT, RIST, or WebRTC.
For better and worse, RTMP and dealing with it at scale is well understood.
> However, Germany ends up taking the prize for most Minecraft servers per capita, with a whopping four servers for every 10,000 people. This is probably thanks to cheap hosting offerings from companies like Hetzner.
Hetzner is a German company, OVH is not. And while OVH has a presence in Germany, if we run this query on Shodan: https://www.shodan.io/search?query=product%3A%22Minecraft%22... OVH is #8 while Hetzner is #2. So I'm not sure why you'd think this is advertising, they're merely providing an example for Germany.
That being said, GPortal is also a German company and #3 overall, but they're a dedicated provider of game servers, rather than commodity servers. Conspicuously absent is Nitrado - also a German company - probably because they run most of their servers on non-default ports, whereas GPortal assigns each server its own IPv4 last I checked.
Why they chose that example I can only speculate, perhaps it was the first name they recognised and just used as an example because they were familiar with it?
I just really didn't like the assertion that this was supposed to be some sort of advert, rather than an arbitrary pick. It certainly isn't an affiliate link or anything.
> I just really didn't like the assertion that this was supposed to be some sort of advert, rather than an arbitrary pick. It certainly isn't an affiliate link or anything.
Feel free to speculate one way or another, I'll do the same based on the data and reasoning provided.
You don't need an affiliate link to advertise btw, referer headers do just fine.
I really wasn't slamming them for advertising, just noting it was and that it didn't fit their reasoning as to why they were plugging them.
If you feel it was an arbitrary selection, that's fine. I was just expanding on the statement as to why it doesn't fit the data. I assume you concede to that right?
To be clear here: They do modify it further than that by applying a number of patches.
For example, they replace libx264 with OpenH264 which also requires some changes to the UI code since it is (unfortunately) hardcoded to expect x264 to exist. While there have been efforts to upstream those changes, they have not yet been merged.