I have a ₹40,000 budget and want to play GTA 6 while livestreaming on YouTube with facecam.

I'm considering renting a PS5 for 3 months, which costs ₹13,719. GTA 6 rental would cost ₹1,000 per month, so ₹3,000 for 3 months. The PS5 rental includes access to around 400 games.

I also want to buy a 100Hz monitor and eventually build a gaming PC, but I don't have enough money for the PC right now.

My current laptop has a Ryzen 3 7000-series CPU, 8GB DDR5 RAM, a 256GB SSD, and integrated graphics.

My questions:

Can I use the official PS5 HD Camera for YouTube livestreaming?

Can I reuse that camera later on my Windows PC with OBS, or should I buy a separate webcam?

Can my current laptop handle PS5 streaming through a capture card and OBS?

Is renting a PS5 for 3 months worth it, or should I save the money for a gaming PC?

I'd appreciate advice from people who have experience with PS5 streaming and PC setups.

I’m working with a team developing a platform where owners can make their gaming rigs available for paid remote gaming sessions during hours they don’t need them.

Players would use their own Steam accounts to play games they own. We’re developing a desktop app for Windows and macOS using Steam Remote Play.

Hosts choose their hourly price and availability. Payments are split 50/50 between the host and the platform, with hosts covering electricity and other operating costs from their share. Only actual paid sessions generate earnings.

From discussions so far, the biggest concerns have been home network security, protecting players’ Steam accounts, residential upload speeds, and whether enough paid usage would make hosting worthwhile.

For people here who already stream games: would you consider being on the hosting side? What would you need to know before trying it, and what would make it a definite no?

cloud gaming suggestion

Hi gyz I'm loooking for a new cloud gaming platform cuz xbox fuked everything up with new november rules. I'm from North India.

GeForce now is too expensive thier ultimate plan and their mid tier plan is out of commission

The only options I have left is boosteroid or oneplay

If anyone reading have experience to share with either of the services id appreciate it before making the purchase. I m mainly buying this to play phantom blade 0 and onibusha etc souls like games (I don't have a gaming pc)

I want to know do they deliver what they promise or not boosteroid and oneplay in india.

Hey everyone! I wanted to share a project I’m developing to play Xbox Cloud Gaming on TV, with a controller-friendly interface and careful memory use.
The goal is to accommodate lower-end TVs and TV boxes, including devices with 1 GB of RAM. Features include:
A visual library with categories, favorites, and recently played games.

Two streaming engines: Native and WebView.

Resolution, bitrate, codec, and region settings.

Streaming stats with ping, FPS, and decoding time.

Friends, profiles, and messaging, plus an embedded official Xbox interface for parties and other actions.

Microphone options and English, Portuguese, and Spanish support.

This is an independent, open-source project. It doesn’t provide games or replace any required subscriptions or purchases. Performance depends on your device and connection, and social and voice features still need more real-world testing.
Source code and instructions: https://github.com/LeuAndrade/Nuvem-TV
If you play on Android TV, what device do you use, and what’s your biggest frustration with cloud gaming? I’d love to hear your suggestions and testing experiences!

Como muchos de ustedes que usan Moonlight/Sunshine, simuladores de carreras o concentradores Raspberry Pi, me cansé del límite de un dispositivo en el plan gratuito de VirtualHere y de la licencia de $49 por servidor.

Por eso creé USBAnywhere v3.0 (antes SnakeUSBIP): un cliente WPF nativo de .NET 9 para Windows 10/11 con controladores certificados por Microsoft WHQL y un instalador de servidor Linux Plug & Play con un solo clic.

Características principales:

🔗 GitHub y versiones: https://github.com/oscarlosu-lab/USBAnywhere

Long and very technical read. Be warned.

I work as a platform engineer for over 15 years now and i have a quirk for optimizing the shit out of things.

So for a while now I've been researching one question: how good can game streaming get on a Radeon if you build the host around AMD's hardware instead of treating it as the third vendor for a fork of NVIDIAS gamestream?

The research is done through Rubylight, an AMD-only host for Moonlight that only cares about optimizations around AMD. It isn't another fork with a new name on it and a fancy sloppy ui that can do all the fancy features but still has 60 hz clients or cheats metrics or something. It does just well enough in the feature part that it reaches a small userbase contributing to feedback on bugs and issues. It's research on AMD, and what we learn goes back where it helps.

We contribute to Vibepollo, and I've asked Nonary about working together more closely.

Here's what the research turned up so far. All numbers are from flagship amd graphic cards. And what changes my work from slop is that most of this here wont change the numbers on your measurements and I dont put some fancy ui in and call it a day.

Every host measures "host processing" its own way, so I measure picture age instead: the test source draws a timestamp barcode into every frame, and an independent receiver reads it back after decoding. That's the time from the moment a picture is rendered to the moment the client has it decoded. It's the same yardstick for every host and you can't game it from the host side.

4:4:4 on an encoder that can't do it

AMD's hardware encoders only do 4:2:0, and AMD's own AMF docs say so for every VCN generation up to 5.0. There are two ways around that.

The first is PyroWave, Themaister's wavelet codec. It runs as Vulkan compute, skips VCN entirely and does full 4:4:4 up to 10-bit HDR. What made it fast under load was moving the RGB to YUV conversion off the graphics queue. With a game running, the conversion sat behind the game's draws and took 5.6 ms a frame. As one compute shader on a high-priority D3D12 compute queue, writing straight into the textures Vulkan imports, it takes 0.55 ms. This number does not show up in any metric in moonlight but will greatly impact glass to glass latency.

The second is packing, which keeps the normal HEVC and AV1 hardware encoders. A 4:4:4 frame has exactly as many samples as a 4:2:0 frame twice as tall. So Y goes in the top half of the luma plane, the odd columns of Cb and Cr sit side by side in the bottom half, and the even columns fill the chroma planes. The encoder sees an ordinary double-height picture, the client decodes it with its ordinary hardware decoder, and a shader puts every sample back exactly where it came from. HEVC and AV1, 8 and 10-bit, all reach about 1440p120 this way, even on a Radeon 780M.

The third is predictive packing for the 10-bit modes. Here the top half of the picture is a normal 4:2:0 frame. The chroma samples 4:2:0 would throw away fill the rest, stored as halved differences from the sample they share a 2×2 block with. On most content those differences are small, so that part of the picture sits near flat grey and costs few bits. Halving costs at most one code value before compression and keeps the encoder's rounding from wrapping a difference around.

Both packed modes are opt-in, since stock Moonlight would just show you the packed picture. Nightjar, our client, unpacks both.

Fenced D3D12 capture

On a virtual display the host doesn't use WGC or Desktop Duplication at all. Our driver copies every frame Windows composes for its monitor into a ring of textures it shares with the host, stamps the present time next to it and signals the host. That ring used to hand textures back and forth with keyed mutexes. Now its textures and fences live on the GPU's D3D12 compute device. The driver signals a "written" fence after its copy, the conversion shader reads the texture in place after waiting on that fence on the GPU, and the compute queue signals a "released" fence when it's done so the driver can reuse the slot. The wait happens on the GPU instead of a CPU thread, and no D3D11 work runs for it.

Claiming a frame went from about 32 µs with the keyed mutex to 1.8 µs. Under GPU load at 1440p120 HEVC, every fence run held a full 120 fresh pictures a second, p99 picture age dropped from 19.3 to 18.1 ms in SDR and from 21.3 to 19.4 ms in HDR, and the p99 frame interval in SDR went from 13.8 to 11.2 ms. That's picture age from the game's render through decode, about 14 ms on average with the GPU busy.

These numbers don't look huge, but mind you we are looking at optimization wherever possible, so they were for me.

Slices

Moonlight asks the host for slices, and I wanted to know what they buy on AMD. I did 630 encoder runs across HEVC and AV1, 1080p up to 7680×2160, 60 to 240 fps, with split-frame encoding forced on, forced off and left alone, then again with 2 and 4 slices. Every variant encoded in the same time, within 0.2 ms. The driver reports two encoder engines, but one stream uses one engine, and slices don't change that.

Where slices can pay off is getting out of the encoder early. AMF can hand back each slice as soon as it's encoded, so you could packetize and send the top of the frame while the bottom is still encoding. That's what I'm testing next. So far its promising if the client supports it. Again that is why I had to also develop a client framework in a language I understand to fully be able to test this and why its so important for me to have my own client/host.

Utilizing Split Frame Encoding

AMD’s VCEEncoderD3D sample from their official AMF repo (commit 57ee0cf), driver 32.0.32015.7029, encoding as fast as it can. Our code wasn’t involved.

fps, 2 runs each Left to driver On Off

HEVC 7680×2160 99.0 / 101.3 101.1 / 101.3 101.1 / 101.3

HEVC 3840×2160 197.1 / 197.1 197.4 / 197.5 197.3 / 197.6

AV1 7680×2160 121.8 / 121.9 121.9 / 121.8 122.0 / 121.9

AV1 3840×2160 238.4 / 239.2 238.3 / 238.4 238.0 / 238.8

So the hardware is there, but the driver gives one stream one engine whatever the setting says. These numbers also line up with our host’s own October 7 runs (100 and 126 fps unpaced at 8K).

The second engine does work: two separate 8K HEVC encodes ran at about 101 fps each, about 203 fps together, against 101 fps alone.

What we are currently testing is we manipulate and use this to our advantage on one frame by using 2 encoders, each taking half the frame. One encodes the top half, the other the bottom half, and they land on different engines (the two-process test just showed both engines run at full speed side by side). Nightjar decodes both halves and stitches them back together. This halves latency in halve down to p95 encoding times of 3ms at 4k but is absolutely nightmarish to implement. Every Frame needs two hardware decode sessions on the client, both halves have to be presented together and the bitrate is split between two encoders, so they can quantize differently and leave a faint seam in the middle. Also recovery after packet loss now has to handle two streams. And no, we cant use slices because of motion prediction. In HEVC (and in AV1 with tiles), slices only make intra prediction and entropy coding independent. Motion vectors still point anywhere in the previous frame, across slice boundaries. The bottom encoder only knows its own half. When an object moves down from the top half, it predicts from its own padded edge, while the decoder uses the real pixels from the top half. Every frame adds a small error, and the picture drifts until the next keyframe. HEVC has a fix for this, motion-constrained tile sets, but AMF doesn’t expose it.

VRR

Thanks to Nonarys findings, the virtual display driver goes up to 1000 Hz, so when the client asks for VRR the desktop doesn't cap the game's present rate. Here's what we do differently to reach more smooth VRR:

1. Rate cap. The host takes each frame as soon as it arrives, but never faster than the stream rate the client asked for. Repeated frames count toward that rate; a frame re-encoded because the client lost packets doesn't. Without the cap, a game running faster than the stream on a 1000 Hz display left every frame short of bits: blurry picture, fringed text, flooded link.
2. Pacing instead of tiny queues. Vibepollo's VRR mode shrinks its queues (WGC frame pool from 2 to 1, low-latency AMF input queue). We keep the queues and change the pacing: predictive waits off, frames can be claimed half a frame period apart instead of three quarters, WGC's slot-aligned publishing off, refresh lock off since a VRR display follows each frame anyway. The encoder holds at most two frames on every stream, VRR or not.
3. Extra WGC compositions. When Windows publishes more compositions than the game produces, the host lines up with the game's real updates. On a 60 fps source that's 57.7 against 59.9-60 fresh pictures a second.
4. Our own display driver. Capture comes straight from it in about 0.2 ms, HDR included.
5. Presenting on the client. Nightjar schedules VRR frames from the host's timestamps without needing a shared clock. A clock-sync message adds latency measurement on top.

Radeon controls in alpha.2

Change AMD Controls like Anti-Lag, Chill, Boost, RIS, the frame cap or AFMF from the couch and get your own settings back afterwards. A probe round-trips every ADLX 3D setting on the installed driver, and only the ones that really write get exposed: 24 with AMD Software 26.9.2. Your original values go into a journal on disk before anything changes, and they're put back when the session ends or the game closes, or at the next start if the host crashed. If you changed a setting on the PC in the meantime, it's left alone. Its a feature that just makes sense. Most of the time, tops having this natively.

Background Streaming

My Children play on my rig while I work at the same time. I use Rubylight and Hyper-V AMD GPU-PV to a VM with Rubylight to isolate input and the game. Works well enough for kids to not notice. https://github.com/RamazanKara/Rubylight/blob/main/docs/configuration.md#background-streaming-from-a-hyper-v-vm

Where the latency goes

At 1080p60 the host stages are capture 0.22 ms through our display driver, conversion 0.26 ms, HEVC encode 2.43 ms and packetizing 0.03 ms. Nearly all of it is the encode. We are looking at microseconds now to find any further optimizations.

The bigger wins came under load:

• Frame prep on the compute queue took average picture age from 41.0 to 33.5 ms with the GPU busy.
• Keeping at most two frames in the encoder took present-to-send from 42.7 to 11.1 ms when the encoder was saturated.
• Giving controllers their own input thread took a mouse move stuck behind a controller update, under full CPU load, from 287 ms to 2 ms.
• approximately 5000 different tests has been done on various AMD quirks and metrics. These led to countless small improvements you can read about in the docs.

Benchmarks

We do not measure AMD with Rubylight against other Sunshine Forks anymore, because the glass-to-glass latency under load is so far ahead that it is just not worth the time. If you want, you can still compare it yourselves. Rubylights test setup is available and there are historic measurements available.

The full measurement record, with methods and every run, is public: PERFORMANCE.md. Questions are welcome, and if you have AMD numbers that disagree with mine, I want to see them. For anybody stable should use vibepollo and wait till that research has been backported. For anyone wanting to contribute test out rubylight 3.0 + nightjar and give feedback in form of issues with logs and so on, please just dont bodly claim host x has better latency under load just from the host processing number, I do not care about that.

Hello im playing wuthering waves on pc, but my phone doesnt run the game and i need to spend my 16$ google balance

If you've kept an old gaming rig after upgrading, would you consider letting other people pay to play on it remotely?

I'm part of a team developing a platform for this. Hosts choose when their rig is available and set an hourly price in credits. Players use games they own, and hosts earn from actual paid playing time. The payment is split 50/50 between the host and the platform, with running costs coming out of the host's share.

We haven't released it yet. We're developing a desktop app for Windows and macOS, using Steam Remote Play.

Hosting requires a dedicated SSD, with personal-data drives physically disconnected while hosting. That alone doesn't resolve home-network security or liability concerns, and actual demand matters when deciding whether the earnings could cover electricity and wear.

For people here who already stream games: would you consider being on the hosting side? What would you need to know before trying it, and what would make it a definite no?

We're interested in making use of hardware people already own, rather than encouraging anyone to buy a rig as an investment.

Galaxy s23, playing xbox cloud in the browser in the evenings. About 30 minutes in the phone gets hot and the stream starts stuttering, even though my connection is fine (ran the tablet at the same time and it was smooth).

Pretty sure it's thermal. My plan is to get a magnetic cooler on the back but the problem is my current clip-on covers most of the back of the phone, so there's nowhere for it to go.

Anyone running a cooler with a clip-on controller? Which ones leave space?