> 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).
> 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.
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.
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.
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.
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.