moonlight-stream / moonlight-ios

GameStream client for iOS/tvOS

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Apple TV (2022 Version) HDR Black Screen

jarronimo opened this issue · comments

The 2022 version of the Apple TV displays a black screen when doing an HDR stream. My 2021 Apple TV has no issues on the same TV, connected to the same computer. SDR streams continue to work fine on the 2022 Apple TV.

Do you happen to have a Mac that you could compile Moonlight with?

The way we enter HDR mode is undocumented and I wonder if we just need to adjust it for the 2022 Apple TV.

I should be receiving my ATV 4K 2022 during this next week and will be able to debug it in case OP can't

Yeah, I can do that.

OK, the line to modify is:

According to MrMC, it seems like 2 or 3 should work, so try changing that line to 3 and see if that fixes it. If not, we'll need to debug further.

I changed it to 3, but the issue persists unfortunately.

Hey @cgutman, my new ATV 4K arrived, and I gave this a go. The problem is not due to the code from MrMc; this is still working just fine. It's something related to sending HDR SampleBuffers directly to AVSampleBufferDisplayLayer; it will just stop displaying new frames as soon as we start receiving Main 10 HDR data. Sadly there's no error msg or anything else that could help debug it; the frames only stop being shown. During the same session, if you go and turn off HDR, then it starts working again.

On the bright side, though, I managed to get it to work using VideoToolbox to manually create my decompression session, decode frames, and send them to the framebuffer; this and the HDR toggling code worked just fine together. felipejfc@c1aa1a9

Confirmed on my end that felipejfc’s change fixed the issue.

@cgutman btw the changes I did in the master branch of my fork here. Enabled less latency and smoother streaming. I changed it back to Direct Submit but included the pts information in each sampleBuffer instead of setting the Display Immediately flag.
This enabled a smooth stream in the ATV as I got in the Nvidia Shield without needing to use the buffer code (under a super stable cable network). I think using display Immediately messes up pacing completely because then the AVSampleBufferDisplayLayer ignores frame time completely.
So I suggest we roll back to DS, but still keep and adjust the pacing code so that we also accommodate for unstable networks.

btw the changes I did in the master branch of my fork here. Enabled less latency and smoother streaming. I changed it back to Direct Submit but included the pts information in each sampleBuffer instead of setting the Display Immediately flag.

Can you submit a PR for this?

So I suggest we roll back to DS, but still keep and adjust the pacing code so that we also accommodate for unstable networks.

The devil is in the details with the pacing stuff. Unless we've got a specific plan of how to adapt pacing to the direct submit model, I think we should just use the old submission technique for in pacing mode. As long as we aren't regressing anything, we don't have to solve everything at once.

'm experiencing this issue at the moment using the new apple tv. Can I expect a new release soon? If not, is it possible to build some branch with the fix and install on my apple tv?

v8.4.0 has been submitted for App Store review with this fix.

This has been released for a while. Closing.