Yeah, I agree 1 and 2 tackle very different problems. For additional context on what I've observed
For 1: I work in the live streaming space and see cases where an input stream may need to be composited, transformed, mixed in, or something and an entire webrtc stream needs to be setup (usually going through some 3rd party service, e.g. twilio). OBS is normally the go to for a single broadcasted show however in the cases I work with it's a lot of shows (independent streams) that need to be managed and generally have rules around how the compositing works. Hiring a person to manage OBS, VMix, etc... is wasteful and expensive in this case (and not necessary). WebTransport helps in being able to deliver audio / video (or any data) to an app and take care of that. If anything I see this technology as making it easier to build apps for AV and hopefully getting rid of some of the reliance on existing broadcast software which is really intended for the traditional studio setup.
For 2: It definitely seems like adoption is growing. Cloudflare supports WHIP/WHEP (in beta), livekit supports WHIP ingress, and Dolby.io supports WHIP/WHEP (although thats not a surprise since Sergio Garcia Murillo works there after the milicast acquisition and he's at the forefront of some of those standards).
Regarding 4, cloud rendering, this is just mainly a use case I've had to deal with more and more of lately where folks are trying to get off OBS and VMix for compositing shows. An example use case is joining streams from multiple sources at scale (usually for large scale LED wall installations and such) and dynamically adding content / graphics based on interaction, data, etc....
It's much easier to program in the rules and have it be re-useable / configurable vs requiring someone to setup OBS scenes (at least at scale). I agree, I don't like the browser dependency (primarily since the devex is quite terrible for all of this). However it seems to be coming from a place of the lowest common denominator. It's easy for someone to whip up a figma/design of what they want and have that translated to html, use a motion library for animating, and stick it into a video feed (especially if you're trying to stick with an existing brand where you may already have a website and web apps with all of that ready to go).
If I understand correctly from checking out the websites, it looks like peertube is focused on Video-on-demand (VOD) and tackling the problem of content delivery and storage. From a technology standpoint I actually feel pretty good about where VOD is currently since HLS / LL-HLS (the more common delivery mechanism I see and also low latency being increasingly supported) is pretty easy to setup with any video provider (CDN, cloud providers, video platforms e.g. mux, livekit egress).
I do see that peertube is using WebRTC (I'm guessing for the P2P aspect). So I'll tackle the question in the two technologies that might need advancing in that space:
1. Peer to peer should be broken out as its own standard in the browser. Right now to implement peer to peer you're stuck with WebRTC which brings in possibly a ton of features you don't need. Also, if you're trying to use it outside of a browser you're pretty much stuck with using libwebrtc which is the de-facto WebRTC implementation and effectively is an entire networking + application + av codec layer.
2. Storage! This probably needs to be re-designed for handling video in the future. No idea how but the issue I see is that usually for VOD you will want to upload a master. The master file is then transcoded to multiple resolutions / formats and such so that folks can view according to bandwidth. This ends up eating up a lot of space. Maybe we need better ways of storing content?
3. Adaptive bit rate / WebRTC delivery. This is the part that might kinda bite peertube if I had to guess. WebRTC is designed for speed over quality. When ABR kicks in the video bitrate drops and you start getting crappier video. In my experience when people are viewing VOD content they usually want things as crisp and clear as possible. This isn't so much of an issue on a conference call or live streams (usually video degrades before audio). For a peer to peer streaming network I'd have to imagine that you'd want more control on how content is delivered and I'm not sure how peertube handles that.
That's just my thoughts off the cuff though, I'll give it more thought though.
Feel free to leave comments if you think I should add anything. I'm creating this information free and open source to try to learn more about the state of current tools
This is great if the assumption is that the startup will be successful, however given the failure rate it feels like the focus should be on risk management. How much risk should I as a developer be willing to invest knowing that statistically things might not work out.
Additionally, it would be great if there was material like this that was much more approachable by someone early on in their career.
What would you classify as remote collaboration? When organizations are more geographically distributed, a rise in work from home / anywhere, or something else. Just trying to better understand your point of view
That's really helpful to know, I had been considering building software geared towards lean / iterative and auto generated documentation as my initial approach into collaboration tools but I will definitely have to start expanding my research
This is really helpful to know. I was thinking of those tools independently but overlooked that people may be using multiple collaboration tools. The part that you mentioned with the tools being "adequate" is where I've been stuck lately. I thought building yet another collaboration tool / software could resolve some of the issues with information getting lost / ease of sharing. Seems like there is more to the problem though