Thanks, my project disabled the ARC (not under my control) and I have to release everything by myself except smart pointer, and it is mostly using C++ instead of Objective-C. If I send dictionary with content of xpc_dictionary_set_data, will retain keep the data memory from freeing immediately after releasing the dictionary, currently I'm sending data buffer to other side, I have to make a copy of the data in receiver side to avoid recv side data copying crash (does xpc recv use the data copy or share the data reference/pointer with sender?). BTW, could I send CMSampleBufferRef via xpc_dictionary? Steven

figured out, the multi-cast UDP

Never mind, I'm sending surface instead and it is working

How do I avoid  IOSurfaceCreateXPCObject crash? right now it is my headache issue.

Thanks, I posted the screenshot since it contains the error information which might help understanding the problem. BTW, that surfaceObj was from callback block of CGDisplayStreamCreateWithDispatchQueue, and its value is not null but not sure if it is valid. auto dspref = CGDisplayStreamCreateWithDispatchQueue( displayId, captureWidth, captureHeight, '420v', opts,            dispatch_queue_create("my_display_data", DISPATCH_QUEUE_SERIAL),           ^( CGDisplayStreamFrameStatus status,  uint64_t time,  IOSurfaceRef surfaceObj,   CGDisplayStreamUpdateRef ref )           { ' Do we have any API to check if it is valid to avoid crash? Do we need release this surfaceObj after sent out the XPC message? I suppose system do the maintenance job for the callback block. Again, ARC was disabled. -Steven

Great, CFRetain fixed the occasional crash issue. Thanks to Quinn :)

I have the same problem, even adjust bitrate it will not work, I set the min bitrate to 2Mbps, the actual is about 0.5Mbps, I'm on Monterey 12.0.1

One extra question, same code of screen capture, xpc module of standalone video tool box H264 encoder (running in native M1 or Intel mode), the video quality of Intel is very good, but with M1, the video is way too blurry, anyone has idea of why this is happening?

BTW, I tried openssl s_client to connect the server, it works ok w/o handshaking complain. openssl s_client -connect 192.168.68.107:7554 but nw_parameters_create_secure_tcp won't work

Tried many options, almost cost me two days, finally got one which is working: auto config_tls = ^(nw_protocol_options_t tls_options) {     auto sec_options = nw_tls_copy_sec_protocol_options(tls_options);     sec_protocol_options_set_min_tls_protocol_version(sec_options, tls_protocol_version_TLSv12);     sec_protocol_options_set_max_tls_protocol_version(sec_options, tls_protocol_version_TLSv12);     sec_protocol_options_append_tls_ciphersuite_group(sec_options, tls_ciphersuite_group_default);     sec_protocol_options_set_peer_authentication_required(sec_options, false);   };

Thanks a lot, looks like I need find other way for it. -Steven

That's a better idea, BTW, one question might be simple to you. when I call xpc_release(connection) after xpc_connection_cancel, it will crash and system complains misuse like libxpc.dylib 0x00007fffd9152504 _xpc_api_misuse + 75 1 libxpc.dylib 0x00007fffd9141b7f _xpc_connection_last_xref_cancel + 52 2 libxpc.dylib 0x00007fffd9141b22 -[OS_xpc_connection _xref_dispose] + 17 If I remove xpc_release, it seems to be ok, and the app didn't enable ARC, does that mean if we called xpc_connection_cancel, even in non-ARC, we don't need call xpc_release? my env is Monterey 12.2 Thanks Steven

BTW, if we call  auto sec_options = nw_tls_copy_sec_protocol_options(tls_options); Do we need nw_release(sec_options) after using sec_options?

Also, this problem nw_protocol_boringssl_signal_connected(724) [C7:1][0x7f793592b300] TLS connected [version(0x0303) ciphersuite(TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) group(0x0017) signature_alg(0x0401) alpn(nil) resumed(0) offered_ticket(0) false_started(0) ocsp_received(0) sct_received(0) connect_time(96ms) flight_time(88ms) rtt(77ms) write_stalls(0) read_stalls(4)]

Apple says network.framework is better than OpenSSL+Socket, I have problem in proving that, anyone has official way of receiving the data? void handleIncomingVideo( void* caller, nw_connection_t connection = nullptr )   { // init processing ... //handle incoming data  nw_connection_receive(         connection,         1,         bufLen,         ^( dispatch_data_t   content,           nw_content_context_t context,           bool         is_complete,           nw_error_t      receive_error ) {           auto isBufferBeginWithStartCode = []( const char* frame ) -> bool {             return ( frame[0] == 0x00 && frame[1] == 0x00 && frame[2] == 0x00 && frame[3] == 0x01 );           };           if ( content != nullptr )           {             // handle received data here ....             // 2. schedule next incoming video recv             nw_retain( connection );             handleIncomingVideo( caller, connection );           }           else           {             // Context is nullptr, schedule the next recv             if ( receive_error == nullptr )             {               nw_retain( connection );               handleIncomingVideo( caller, connection );             }           }         } );  The video (H264 stream) quality is not as good as my old openssl + socket, and sometime cannot no video data come in, while old openssl+socket doesn't have this issue. Am I using it correct?