To clarify the issue, our preview pipeline rotates the sample-buffer display layer by applying the RotationCoordinator angle as a transform on the layer itself, while leaving the data-output connection's rotation unset — a pattern that worked on every iPhone before 17 Pro because the buffer always arrived in the same default orientation. On the iPhone 17 Pro front cam the same code renders 90° off: RC still returns correct values, but the buffer's default orientation is itself 90° offset from every earlier device, so "RC's angle applied as a layer transform" no longer lands upright. The hidden dependency that broke is exactly this — applying RC's angle on the layer only works when the buffer's default orientation is fixed across devices, and since we never set the connection's rotation, we were silently relying on that default, which shifted on this one camera. The supported fix (driving connection.videoRotationAngle directly) corrects orientation but causes the emitted buffer's pixel dimensions to swap between portrait and landscape(1920x1080 to 1080x1920, which then breaks the preview aspect-ratio layout and the AVAssetWriter transform that were both built around stable buffer dimensions.

Dear AVFoundation Engineers, Here is a workaround I found (apart from unconfiguring and reconfiguring AVCaptureSession). It works by removing VDO from captureSession and adding it back and resetting pixel format to 32BGRA, any other pixel format fails! Your comments awaited. captureSession.removeOutput(videoDataOutput) //Workaround to reset deviceformat back to SDR captureSession.sessionPreset = .high isHDRVideoEnabled = false //Only 32BGRA works, setting it to YUV420 8 bit full range fails! if videoDataOutput.availableVideoPixelFormatTypes.contains(kCVPixelFormatType_32BGRA) { print("Setting sdr pixel format \(kCVPixelFormatType_32BGRA)") videoDataOutput.videoSettings = [kCVPixelBufferPixelFormatTypeKey as AnyHashable as! String : kCVPixelFormatType_32BGRA] } captureSession.addOutput(videoDataOutput) //End workaround try currentDevice.lockForConfiguration() currentDevice.activeColorSpace = .sRGB currentDevice.unlockForConfiguration()

@DTS Engineer I spent sometime and enabled concurrency checks to complete in the compiler options. I was able to fix two main sources of warning (which are error in Swift 6) by changing the definition of two functions as follows: func capturePhoto(with features: PhotoFeatures, isolation: isolated (any Actor)? = #isolation) async throws -> Photo func stopRecording(_ isolation: isolated (any Actor)? = #isolation) async throws -> Movie Effectively, I forced these functions to be called from the isolation domain of an Actor (which is actor CaptureService in the source code). I believe this should be okay as this is the only place where these functions are invoked. However, there is one place in the code where I still need help: override func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey: Any]?, context: UnsafeMutableRawPointer?) { switch keyPath { case systemPreferredKeyPath: // Update the observer's system-preferred camera value. let newDevice = change?[.newKey] as? AVCaptureDevice continuation?.yield(newDevice) default: super.observeValue(forKeyPath: keyPath, of: object, change: change, context: context) } } The line continuation?.yield(newDevice) throws a warning that Task-isolated 'newDevice' is passed as a 'sending' parameter; Uses in callee may race with later task-isolated uses. Is this because AVCaptureDevice is not Sendable?

That requires modifying hundreds of CI kernel methods, not a good workaround.

Dear Apple Engineers/DTS, Is there any answer for this question?

I am facing the same issue, no idea how to fix it.

Still waiting for an answer here.

Here is the link to download the test project from Github to reproduce the issue. Feel free to point out what is wrong and needs to be fixed.

@galad87 The plist itself is type CFData in this case. Nothing works as I said, including the second code sample I posted in the question where I simply copy and paste the attachment from source sample buffer. Feel free to modify and post the sample code you think should work.

@Jason It seems AVAssetWriter is crashing with error -12743 when appending NSData for kCVImageBufferAmbientViewingEnvironmentKey. Please describe how exactly to copy this attachment to new pixel buffer. Here is my code: var ambientViewingEnvironment:CMFormatDescription.Extensions.Value? var ambientViewingEnvironmentData:NSData? ambientViewingEnvironment = sampleBuffer.formatDescription?.extensions[.ambientViewingEnvironment] let plist = ambientViewingEnvironment?.propertyListRepresentation ambientViewingEnvironmentData = plist as? NSData And then attaching this data, CVBufferSetAttachment(renderedPixelBuffer, kCVImageBufferAmbientViewingEnvironmentKey, ambientViewingEnvironmentData! as CFData, .shouldPropagate)

Dear Core Image Engineering Team, I wasted a DTS credit to get this answered and all I was advised was to debug using CIPrintTree and look for "optimisations" where there is none possible (the code I submitted with the bug report contained minimal CIImage rendering pipeline). The DTS engineer acknowledged the significant difference in CPU usage between Metal and Core Image pipeline but was unable to offer anything except recommending filing a bug report. I have already filed FB12619176 and looking to hear directly from Core Image Engineering team. Because high CPU usage is a no-no for using Core Image for video pipelines. It might be okay for photo editing but not for live video or video editing tasks.

I tried setting activeColorSpace to .appleLog whenever the device.activeformat.colorSpaces contain .appleLog. But somehow it doesn't works.

I adopted Core Image instead of Metal as it was recommended by Core Image team in various WWDC videos such as wwdc2020-10008 but only to realize that my UI is getting slower due to very high CPU usage by Core Image (as much as 3x-4x compared to raw Metal). It seems I need to rewrite the entire filter chain using plain Metal unless there is a workaround for high CPU usage. I have submitted a feedback request to DTS with a fully reproducible sample code. Really looking forward to answers by Core Image team here.

Can someone from Apple please respond to this?

Same issue with XCode 14.3.1 and Cocoapods 1.12.2