Future of aperture

[JeDaYoshi]

Note that aperture is getting even closer from being deprecated, more when WebRTC is being integrated on Cryb.
Support might be left, but requires some rework as of how it works

At its current state, aperture will not scale well. It's not optimized, and it's not ideal to center all VM streams into a same endpoint, and that same endpoint stream to clients, especially network-side.

@cryb/portal could get some work to stream directly to clients, and if much, fallback to this when it's not possible for any reason.

Also needs more work as of how it works in that case, instead of only sending all the data to everyone.

From #3:

I've been looking into how aperture streams stuff - it needs some fixes and adding features on what is slow network handling, and what most surely will want - real-time streaming, and working around so it doesn't freezes every few due to slow networks.

By what I see - ffmpeg records all the stuff, then aperture just sends the data to the clients, as-is, and won't even do frame skipping etc. to prevent some issues. This would be an issue with those with slow networks and computers, so what's proposed is:

• Do multiple encodings of the stream, in SD and HD. Doesn't needs all of them be running at once, just depending if there's any client requesting for it, based on their situation.
• Check the performance of network and stream and switch automatically to the best choice.
• Do some skipping in case of high loss, instead of getting the whole stream which would desync stuff between viewers and cause some freezing in some cases.

But that's kinda some curious work. Probably it might get a little of checking.

[JeDaYoshi]

Seriously considering deprecating this, but I want to leave support for those who don't want to do WebRTC, but this doesn't works properly unless something fun is done.

[Soliel]

I think we should mark a build as Last Aperture Release then cut it out entirely. It's bloating the player component in ways I'm not comfortable with, and requiring additional logic to handle differences between them.

[AznManDown]

I'm in agreement with Soliel. Leaving something in to give people an alternative, especially when the alternative has issues and is less functional just doesn't make any sense. We should cut out Aperture and just focus on MediaSoup (Thanks, Soliel).

[JeDaYoshi]

It's honestly the right thing. Streaming MPEG1 via a TLS connection is not the best thing and hasn't been since a start. I suppose that, unless it is changed how it works, it'd be a waste of time to try to keep maintaining that, in special that WebRTC will fit most people's needs.

[Soliel]

Then here's my plan:

Je-da, finish the queue status stuff for Api and Web. We'll call that a good stoppage point. It doesn't seem like too many people are using Aperture anyway, but let's announce it in discord.

We'll mark that release as last aperture release. I think this is a good point to do so because most people using aperture are running small instances with <20 users. so any account management can be done by a server owner. reducing the need for account management stuff which should be our next milestone to go with Mediasoup.

If everyone agrees to that we can get to it and close this issue when the release comes out.

We'll branch every repo with the name aperture-release and then strip all aperture code from master in the next release.