(unsupported h265/hevc video)Larger resolution than 1920x1080 (h265 video from recent-generation client with wired connection, not wifi)

[ionull]

When I set it to 2560x1440 or larger, there's only error log from VLC: unexpected partitioned VCL NAL unit: nalu_type = 2, ref_idc = 0, nalu_size = 3793,processed bytes 4, payloadsize = 3797 nalus_count = 1 unexpected partitioned VCL NAL unit: nalu_type = 2, ref_idc = 0, nalu_size = 3793,processed bytes 4, payloadsize = 3797 nalus_count = 1

[ionull]

log-testing.txt

[fduncanh]

Thanks!

But I dont understand what kind of video your macOS client is sending... (The M2 2023 macbook pro running Sonoma 14.0 used for testing sends regular H264 video that UxPlay expects)

I wonder if your mac is sending video in the newer h265 video format instead of h264?

The decryption is working correctly.

After the initial unencrypted packet with a length-0 payload, there is an initial large video payload beginning "28 01 af 56 ......" that is being interpreted as a h264 format "type 8" NAL unit (because of the second entry "8") After that, the video payloads all start as

02 01 d0 01 ...
02 01 d0 02 ...
02 01 d0 03 ...
etc

and are being interpreted as type 2 h264 nal units

in addition the initial large "type 8" nal occasionally gets the size "2560x1440" output while it is printing, probably by some other thread in uxplay which I could not identify (???)

...
b6 f5 b5 15 16 cd 34 a3 06 11 a5 86 9b ee be 1d 
85 ac 9b fe 03 76 a2 6c 4d fe d3 9c 72 66 2d 70 
3d 68 33 81 63 4b 7b 76 9f f0 07 1f fc 37 82 f7 2560x1440
f0 21 a4 43 d7 49 b4 7c 07 7a 35 cb e4 61 94 a4 
4f 72 a6 d8 98 a4 35 1c 51 90 c9 f4 52 95 6c 0f 
db 94 d6 45 b6 a7 b3 3e 39 b2 9a 95 a9 0d d3 12 
5f 81 89 a7 d4 c0 b3 83 16 73 65 c2 c2 2d 05 7c 
...

[fduncanh]

H265 info for reference

https://programmer.help/blogs/5c647da7dc2d1.html

If this is H265 (high-def) video, the initial bytes 28 01 (first packet) is consistent with a "type 20" H265 NAL = "NAL_UNIT_CODED_SLICE_IDR_LP"

and the subsequent numbered packets with initial bytes 02 01 would be "type 1" H265 NAL = "NAL_UNIT_CODED_SLICE_TRAIL_R"

This make sense, the initial VCL (video image) NAL in h264 is "type 5" "IDR slice-layer without partitioning", and the subsequent ones are are "type 1" ("non-IDR, slice layer without partitioning")

• In principle, supporting h265 would just require identifying it as different from the expected h264 video, and adding a GStreamer video renderer for h265 video. But right now that's not going to happen. Instead uxplay should identify that it is receiving h265 instead of h264 video, and issue a meaningful error message.

Since a M2 2023 macbook seems to stream h264 video by default when -s 2560x1440 is specified, maybe your M1 macbook has some setting set to "high-definition video" (which is a codeword for h265) that can be switched off.

[ionull]

M1 Pro stream h264 when there is no cable connected as well ;)

[fduncanh]

It's possible that there is a "features" setting (a 64 bit bit string) that uxplay sends to the client that could tell it only to send h264 video? I'll try to look into that

[fduncanh]

@ionull I just added detection of h265 packets, with an error message that keeps repeating until the user closes the connection. (I didn't work out how to just close the connection gracefully, so a new connection could be made)

At some time in the future, h265 support might be easy to add, but not now.

Perhaps you could test to see that the h265 you send is detected with an error message.

It's in the latest github master branch.

Thanks for your input sorry we haven't fixed your issue

[ionull]

Ok, thanks anyway for trying hard.

[ionull]

265 can achieve up to 50% more compression than H. 264, which means that it can transmit the same quality video using less bandwidth or storage. This makes H. 265 ideal for high-resolution video formats such as 4K and 8K.

I hope we will have H265 on this project. You still can contact me for testing ;)

[fduncanh]

@ionull

in principle it is not difficult to add h265. An ipad pro m2 6 gen is also available for testing.

The issue is how to get iPadOS or macOS to send h265 video by airplay.

Can you clearly document here (full instructions) what you do with cables etc. to get h265 video sent by airplay?

[ionull]

1. I have a dock with ethernet port, connect MBP to the dock by thunderbolt.
2. Connect dock and Ubuntu with ethernet cable.
3. Install isc-dhcp-server on Ubuntu and write conf set subnet 10.5.5.0
4. Set ethernet ip to 10.5.5.1 : sudo ifconfig enp4s0f0 10.5.5.1
5. Start or restart the dhcp server: sudo systemctl restart isc-dhcp-server
6. Check the dhcp server status: sudo systemctl status isc-dhcp-server
7. Ping from MBP: ping 10.5.5.1 to make sure the network work
8. Start uxplay

[fduncanh]

thanks

[ionull]

@fduncanh instead of setup dhcp server. You can easily share network on Ubuntu: https://askubuntu.com/a/553374/1737826

[fduncanh]

WE managed to test.

The underlying problem is that the Apple client is not including the 3 unencrypted h265 NAL units (VPS, SPS, PPS) needed to decode the h265/hevc video stream with the initial video packet.

Maybe this is because UxPlay is not using full encryption of communications? see #233