CMIO Extension - mostly working; I'm trying to narrow down some edge cases which appear to be related to the buffering of CMSampleBuffers arriving via a sink stream and being subsequently vended to clients via a source stream. The sink stream may not be an issue, I cross posted about the boilerplate CMIO extension having problems with multiple clients. In particular I have a case where two clients are running and the flow of sample buffers is smooth until I connect a third client (based loosely on RosyWriter ported to Mac). I think this third client has a much different cadence of consuming the CMSampleBuffers because it's using AVAssetWriter to asynchronously write the buffers to disk. It seems under this load the CVPixelBufferPool inside the extension runs out of CVPixelBuffers. For reference, my CFPlugIn DAL sample driver is functioning correctly (obviously not on Ventura) with this RosyWriter-esque client so I suspect its the buffering between the client and the extension. Hoping for some hints about what kind of buffering is between the client and the extension. To that end, is there any clarification on: What values might be appropriate for CMIOExtensionPropertyStreamSinkBufferQueueSize? I have it randomly set to 3 in my complex extension. Also, if the sink client disconnects, it is necessary to set CMIOExtensionPropertyStreamSinkEndOfData? Does the CMIO system read or interpret CMIOExtensionPropertyStreamSinkBufferUnderrunCount? Is it even necessary to expose any of these properties to the CMIO subsystem? Or can I remove them and let CMIO infer default values? Some os_log messages that seem to be related to presentation timestamps: CMIO_Unit_Synchronizer_Video.cpp:1435:SyncUsingIntegralFrameTiming observing getting frames too quickly by a lot: 284681993 : 100000 < 284682999 : 100000 (-0.0101), prev time / dur: 284682180 : 100000 / 8189 : 100000 : dropping this frame CMIO_Unit_Synchronizer_Video.cpp:1470:SyncUsingIntegralFrameTiming here's the normal bounding info: 284681993 : 100000 < 284686275 : 100000 (-0.0428), prev time / dur: 284682180 : 100000 / 8189 : 100000 : dropping this frame

I have solved most of the obvious challenges with CMIO Extensions but am finding some strange edge cases that are proving difficult to debug. I have a CMIO Extension which is essentially the straight boilerplate code from the Xcode template. I always return here when I have strange behaviour just in case it's my strange behaviour and not the system. The problem appears on Ventura 13.1 (Apple Silicon - I'll also check Monterey when I'm back at that machine later tonight). The CMIO Extension is installed and recognized. If I launch QuickTime Player and start a recording, everything looks good. If I also launch Photo Booth while QuickTime is running, the camera frames are also streaming. However, if I start quitting and launching QuickTime and Photo Booth to force disconnection/connection events in the extension eventually there are some messages spewed into the os_log by CMIO, the frames stop running and QuickTime hangs when I try to quit.

_streamSinkIn = [[CMIOExtensionStream alloc] initWithLocalizedName:localizedName streamID:streamInputID direction:CMIOExtensionStreamDirectionSink clockType:CMIOExtensionStreamClockTypeHostTime source:self]; Attempting to publish a CMIOExtensionStream with the 'sink' direction (i.e. print-to-tape) as alluded to in Brad Ford's presentation. Any attempt to create such a stream yields and invalid argument exception and if you examine the header files all the init methods are described as returning stream instances that source data (ie camera publishers). *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Invalid argument'

Can 3rd party developers create broadcast extensions bundled inside macOS apps? If running on Apple Silicon macOS, will broadcast extensions embedded in iPhone and iPad apps installed on the mac expose streaming services to mac apps?