H.265 video in UxPlay #339
connorh315
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Needless to say it's not beautiful when you have h264 video on a 4k display which is why I'm quite desperate to find out how h265 works in AirPlay.
I've done some research into this:
The current issue was that H265 could be triggered (unintentionally) by connecting the sender to a network through wired means, but this did not send a complete and required set of data to be able to decode the h265 stream.
Originally I read that h265 might require HomeKit pairing, I thought that was a valid idea so I implemented it, hoping that it would make the connection instantly switch to h265 (or even trigger the correct information to be sent with h265 that wasn't being sent) but nothing appeared
Then I thought that it was maybe a display setting that had to be sent, I included the "receiverSupports444" as I assumed that the 444 part was in reference to HEVC 4:4:4 encoding. Again no luck.
I then questioned whether or not it was an event might be triggered where the server would request an upgrade so I MITM-ed the event channel and again no avail.
That only really left me with the already existing handshake that is very well implemented in UxPlay already and I assumed it was just some setting that wasn't being sent to the client.
I looked into the features set and what each bit that was being sent by an Apple TV 4K/MacBook meant. h265 is a more recent addition to the AirPlay protocol so it would be in the more significant 32-bits if it was a feature. I decided to individually enable each bit that wasn't being used by UxPlay (that also wasn't already labelled as something else such as audio or CarPlay etc.) until eventually I reached bit 39. It wasn't bit 39 that I turned on though as I actually looked 3 lines down at bit 42 being called ScreenMultiCodec. Enabling this bit begins a correct h265 stream. It is clear that this is a h265 stream as the first packet sent by the sender has a header that is plastered with references to "hvc" and "hevc".
Just a small conclusion as to what I think is going on here:
I do think that wired connections causing an involuntary h265 stream is actually a logic bug. I just find it so strange that it sends a stream with missing information simply because 1 bit is off but only if you're plugged into the network. I really don't think it's intentional, I just think it's a mistake, and obviously one that Apple themselves would not realise as none of their receivers would have advertised for a screen res. greater than 1080p but not offer h265. This has to be the case as the HD 32GB Apple TV supports H265 decoding and I believe is the first Apple TV to do so. There is no Apple TV that outputs a higher res. that was released before this model and as such no possibility of having a high res output to trigger this very unique bug.
I'll try and have a crack at this h265 stuff now that I understand it. This was just a write-up of what I've discovered just in case I don't get round to it. I guess I should probably fix up some of the other pull requests I've opened so far that are a bit of a mess!
I'll use this discussion to post any further findings that I have until eventually I open a pull request.
Beta Was this translation helpful? Give feedback.
All reactions