Dive into the world of video on Apple platforms, exploring ways to integrate video functionalities within your iOS,iPadOS, macOS, tvOS, visionOS or watchOS app.

Video Documentation

Posts under Video subtopic

Post

Replies

Boosts

Views

Activity

Why does an edited 4K 60 FPS video become significantly smaller than the original when exported from the Photos library?
I'm observing an interesting behavior on iOS when uploading edited videos from the Photos library. Scenario Device: iPhone Video: 4K, 60 FPS Original video size (Photos app): 660 MB Uploaded original asset: 660 MB After applying a simple edit (e.g., a filter) in the Photos app: Photos app still shows the edited video. When my app uploads the current/edited asset, the uploaded file size becomes 167 MB. So the edited version is approximately 75% smaller than the original (660 MB → 167 MB), even though the duration appears unchanged. Questions Is this expected behavior for edited videos in the Photos library? Does iOS automatically re-encode edited videos using a lower bitrate or a different codec (e.g., HEVC) when generating the current rendition? Does the Photos app continue to display the size of the original asset rather than the size of the edited rendition? I'm aware that PhotoKit allows retrieving both the original and the current (edited) versions of a PHAsset. In this case, I'm intentionally retrieving the current version, and this behavior is observed only for the edited asset.
1
0
193
5d
iOS 27 beta: Opening Notification Center pauses AVPlayer playback
Since iOS 27 beta we are seeing a behavior change in our video streaming app and I would like to know whether others can reproduce it. Behavior on iOS 27 beta: Fully opening the Notification Center pauses playback. Audio continues for about 5 more seconds, then the app is suspended. Closing the Notification Center leaves the player paused. On iOS 26 the same build keeps playing in this situation. Setup: AVQueuePlayer playing video with audio, not muted audiovisualBackgroundPlaybackPolicy = .automatic (default) AVAudioSession category .playback, UIBackgroundModes: audio entitlement AVPictureInPictureController attached with canStartPictureInPictureAutomaticallyFromInline = true Filed as FB23893965 Questions: Can anyone reproduce this on iOS 27 beta? Is this intentional or a regression?
0
2
193
1w
Why does retrieving the `PixelBuffer` of only one eye improve performance significantly on 2020 Mac mini?
Hi all! I'm maintaining a 3D video player, it's great to see we've developed MV-HEVC packed with great features that media industry love to use. This player uses macOS AV frameworks to decode MV-HEVC and plays time-interleaving signal on capable devices, such as DLP-Link projectors, 3D vision glasses syncing devices, etc. Previously, the player output was flickering, unstable when playing MV-HEVC, and I thought it was due to M1 didn't have hardware decoder for it, or 4K Dolby Vision decoding was too demanding for my Mac, but out of luck, I tried retrieving only 1 eye for each frame output during the DisplayLink call, and the flickering is gone. At least that's what I've seen with a 100Hz screen while testing. Why is the performance improvement so significant? And is there other ways I can improve the performance, and perhaps the energy consumption? The link to the change I've committed
0
0
214
2w
AVPlayerController. Internal constraints conflicts on tvOS.
I’m getting Auto Layout constraint conflict warnings related to AVPlayerController in my tvOS project. This issue can be reproduced in an empty tvOS project either by simply using an AVPlayerViewController as a initial view controller or by presenting it. tvOS 26.2 Simple empty project with only one controller: import UIKit import AVKit class PlayerViewController: AVPlayerViewController { override func viewDidLoad() { super.viewDidLoad() } } After presenting that view controller, the following Auto Layout constraint conflict warnings appear in the console: Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. ( "<NSLayoutConstraint:0x60000212f5c0 UIStackView:0x103222520.width >= 217 (active)>", "<NSLayoutConstraint:0x60000212f610 H:|-(>=95)-[UIStackView:0x103222520] (active, names: '|':UIView:0x103216630 )>", "<NSLayoutConstraint:0x60000212f660 UIStackView:0x103222520.trailing == UIView:0x103216630.trailing - 95 (active)>", "<NSLayoutConstraint:0x60000212f7a0 H:|-(0)-[UIView:0x103216630] (active, names: '|':_AVFocusContainerView:0x10333aea0 )>", "<NSLayoutConstraint:0x60000212f7f0 UIView:0x103216630.trailing == _AVFocusContainerView:0x10333aea0.trailing (active)>", "<NSLayoutConstraint:0x6000021309b0 '_UITemporaryLayoutWidth' _AVFocusContainerView:0x10333aea0.width == 0 (active)>" ) Will attempt to recover by breaking constraint <NSLayoutConstraint:0x60000212f5c0 UIStackView:0x103222520.width >= 217 (active)> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger. The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKitCore/UIView.h> may also be helpful. How can I fix this issue? Thanks.
2
0
245
2w
Is it safe to use undocumented VT encoder profiles for 4:4:4 encoding?
While working with VTCompressionSession, I noticed some profiles that were returned by the VTSessionCopySupportedPropertyDictionary but were not documented in header files (other than appearing in the VideoToolbox.tbd file). Specifically: kVTProfileLevel_HEVC_Main44410_AutoLevel kVTProfileLevel_HEVC_Main444_AutoLevel kVTProfileLevel_H264_High444Predictive_AutoLevel If I manually define these, they do seem to work OK (macOS/Xcode 26.4). I expect the answer will be that they are undocumented for a reason, but hasn't 4:4:4 encode been a feature for a while?
0
0
198
3w
iOS 26.4 regression: The `.pauses` audiovisual background playback policy does not pause video playback anymore when backgrounding the app
Starting with iOS 26.4 and the iOS 26.4 SDK, the .pauses audiovisual background playback policy is not correctly applied anymore to an AVPlayer having an attached video layer displayed on screen. This means that, when backgrounding a video-playing app (without Picture in Picture support) or locking the device, playback is not paused automatically by the system anymore. This issue affects the Apple TV application as well. We have filed FB22488151 with more information.
2
0
788
3w
AVQueuePlayer unexpectedly performs network requests during offline HLS playback after several queued episode transitions
Hello, We are investigating an issue with offline HLS playback using AVQueuePlayer and would like to know whether anyone else has experienced similar behavior. Issue We download HLS content using AVAssetDownloadURLSession and play it offline using AVQueuePlayer. For some titles (but not all), after several consecutive episode transitions, the player unexpectedly attempts a network request while the next episode is already queued and the current episode has approximately 60 seconds remaining. If the device is offline, playback fails with: NSURLErrorDomain Code = -1009 and the next episode never starts. Characteristics The issue only affects certain titles. It is fully reproducible for affected titles. For example, if it occurs between Episodes 5 and 6 after starting playback from Episode 1, it always occurs at the same point when replaying from Episode 1. If playback starts directly from Episode 5, the issue does not occur. The issue only occurs when using AVQueuePlayer. Replacing the current item (removeAllItems() + replaceCurrentItem(with:)) avoids the issue, although this is unfortunately not a viable workaround because it breaks our Picture in Picture episode transition behavior. We compared the downloaded packages (boot.xml, Master Playlist, and Stream configuration) between affected and unaffected titles, but so far have not identified any meaningful structural differences that explain the behavior. Questions Has anyone experienced similar behavior with: offline HLS (.movpkg) AVQueuePlayer unexpected network requests during queued playback NSURLErrorDomain Code=-1009 even though the content is downloaded for offline playback If anyone has seen a similar issue or has any information, observations, or suggestions for further investigation, I would greatly appreciate hearing from you. For reference, I have already submitted this issue through Feedback Assistant. Feedback ID: FB23487817 Thank you in advance for any information.
2
0
360
3w
AVCaptureDevice.uniqueID for UVC video devices is unstable - bug or overstated documentation?
The documentation for AVCaptureDevice.uniqueID states the following: Capture devices have a unique identifier that persists on one system across device connections and disconnections, application restarts, and reboots of the system itself. You can store the value returned by this property to recall or track the status of a specific device in the future. For UVC capture devices this documentation does not hold. The video uniqueID is a hex string of the form 0x, and the identifying half is the locationID (bus number plus port path). Which identifies a port, not a device. I ran a suite of tests with three identical Elgato 4K X capture cards connected to a Mac Studio w/ M3 Ultra running macOS 26.5.2, and reproduced my findings on a MacBook w/ M3 Pro (same macOS version). See the script at the bottom of the post for how uniqueId & USB serial number are being retrieved. 1. The uniqueID follows the port. Swapping two cards between two built-in ports swaps their uniqueIDs: # Before swap. 4K X uid=0x2000000fd9009b serial=A7SNB50424UBQI 4K X uid=0x12000000fd9009b serial=A7SNB504219J0R # After swapping the cards between the same two ports. 4K X uid=0x2000000fd9009b serial=A7SNB504219J0R 4K X uid=0x12000000fd9009b serial=A7SNB50424UBQI An app that stored 0x2000000fd9009b to recall a specific capture card now silently opens another. 2. A reboot alone can swap uniqueIDs. External USB controllers (here, PCIe USB cards in two Thunderbolt enclosures) can race for bus numbers at boot, so with every cable left in place, a reboot swapped two of the cards: # Before reboot. 4K X uid=0x262000000fd9009b serial=A7SNB504219J0R 4K X uid=0x252000000fd9009b serial=A7SNB50423R73R # After reboot, no cables touched. 4K X uid=0x262000000fd9009b serial=A7SNB50423R73R 4K X uid=0x252000000fd9009b serial=A7SNB504219J0R This behavior is intermittent, a second reboot changed nothing, but a third caused another swap. Cards left alone in built-in ports retain their uniqueIDs across reboots in my testing; the failure requires dynamically enumerated external USB controllers. 3. Even the product ID tail can drift. One unit intermittently enumerates with idProduct 0x009c instead of 0x009b, same port (USB PCIe card in a Thunderbolt enclosure), cables untouched: # Before reboot. 4K X uid=0x222000000fd9009b serial=A7SNB50424UBQI # After reboot. 4K X uid=0x222000000fd9009c serial=A7SNB50424UBQI IOKit and AVFoundation agree each boot... So the change is upstream of both? I'm uncertain where to place blame for this specific issue (UVC device or macOS). Audio on the same physical units is unaffected. The audio uniqueID (AppleUSBAudioEngine:...:<serial>:...) embeds the USB serial and stayed stable through every test. So AVCaptureDevice can provide a stable per-device identifier, just not for UVC video devices. Questions: Is this a bug, or is the documentation overstating the persistence guarantee for USB video devices? What is the supported way to identify a specific physical UVC video device across reboots and port changes? The USB serial number is stable and is what I've fallen back on via IOKit, but there is no documented AVFoundation API to retrieve USB serial number from a UVC video AVCaptureDevice. Related: thread 803759, where the locationID-derived format is described. Script used for all output above (swift ./list-uvc.swift): import AVFoundation import IOKit func usbSerial(forLocation location: UInt32) -> String? { var iterator: io_iterator_t = 0 guard IOServiceGetMatchingServices(kIOMainPortDefault, IOServiceMatching("IOUSBHostDevice"), &iterator) == KERN_SUCCESS else { return nil } defer { IOObjectRelease(iterator) } var result: String? var service = IOIteratorNext(iterator) while service != 0 { var loc: UInt32 = 0 if let ref = IORegistryEntryCreateCFProperty(service, "locationID" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let num = ref as? NSNumber { loc = num.uint32Value } if loc == location, let ref = IORegistryEntryCreateCFProperty(service, "USB Serial Number" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let serial = ref as? String { result = serial } IOObjectRelease(service) if result != nil { break } service = IOIteratorNext(iterator) } return result } let session = AVCaptureDevice.DiscoverySession(deviceTypes: [.external], mediaType: .video, position: .unspecified) for device in session.devices { let uid = device.uniqueID let location = UInt32(truncatingIfNeeded: strtoull(uid, nil, 16) >> 32) let serial = usbSerial(forLocation: location) ?? "N/A" print("\(device.localizedName) uid=\(uid) serial=\(serial)") }
1
0
308
4w
AVCaptureDevice.uniqueID for UVC devices is unstable - bug or overstated documentation?
The documentation for AVCaptureDevice.uniqueID states the following: Capture devices have a unique identifier that persists on one system across device connections and disconnections, application restarts, and reboots of the system itself. You can store the value returned by this property to recall or track the status of a specific device in the future. For UVC capture devices this documentation does not hold. The video uniqueID is a hex string of the form 0x<locationID><vendorID><productID>, and the identifying half is the locationID (bus number plus port path). Which identifies a port, not a device. I ran a suite of tests with three identical Elgato 4K X capture cards connected to a Mac Studio w/ M3 Ultra running macOS 26.5.2, and reproduced my findings on a MacBook w/ M3 Pro (same macOS version). See the script at the bottom of the post for how uniqueId & USB serial number are being retrieved. 1. The uniqueID follows the port. Swapping two cards between two built-in ports swaps their uniqueIDs: # Before swap. 4K X uid=0x2000000fd9009b serial=A7SNB50424UBQI 4K X uid=0x12000000fd9009b serial=A7SNB504219J0R # After swapping the cards between the same two ports. 4K X uid=0x2000000fd9009b serial=A7SNB504219J0R 4K X uid=0x12000000fd9009b serial=A7SNB50424UBQI An app that stored 0x2000000fd9009b to recall a specific capture card now silently opens another. 2. A reboot alone can swap uniqueIDs. External USB controllers (here, PCIe USB cards in two Thunderbolt enclosures) can race for bus numbers at boot, so with every cable left in place, a reboot swapped two of the cards: # Before reboot. 4K X uid=0x262000000fd9009b serial=A7SNB504219J0R 4K X uid=0x252000000fd9009b serial=A7SNB50423R73R # After reboot, no cables touched. 4K X uid=0x262000000fd9009b serial=A7SNB50423R73R 4K X uid=0x252000000fd9009b serial=A7SNB504219J0R This behavior is intermittent, a second reboot changed nothing, but a third caused another swap. Cards left alone in built-in ports retain their uniqueIDs across reboots in my testing; the failure requires dynamically enumerated external USB controllers. 3. Even the product ID tail can drift. One unit intermittently enumerates with idProduct 0x009c instead of 0x009b, same port (USB PCIe card in a Thunderbolt enclosure), cables untouched: # Before reboot. 4K X uid=0x222000000fd9009b serial=A7SNB50424UBQI # After reboot. 4K X uid=0x222000000fd9009c serial=A7SNB50424UBQI IOKit and AVFoundation agree each boot... So the change is upstream of both? I'm uncertain where to place blame for this specific issue (UVC device or macOS). Audio on the same physical units is unaffected. The audio uniqueID (AppleUSBAudioEngine:...:<serial>:...) embeds the USB serial and stayed stable through every test. So AVCaptureDevice can provide a stable per-device identifier, just not for UVC video devices. Questions: Is this a bug, or is the documentation overstating the persistence guarantee for USB video devices? What is the supported way to identify a specific physical UVC video device across reboots and port changes? The USB serial number is stable and is what I've fallen back on via IOKit, but there is no documented AVFoundation API to retrieve USB serial number from a UVC video AVCaptureDevice. Related: thread 803759, where the locationID-derived format is described. Script used for all output above (swift ./list-uvc.swift): import AVFoundation import IOKit func usbSerial(forLocation location: UInt32) -> String? { var iterator: io_iterator_t = 0 guard IOServiceGetMatchingServices(kIOMainPortDefault, IOServiceMatching("IOUSBHostDevice"), &iterator) == KERN_SUCCESS else { return nil } defer { IOObjectRelease(iterator) } var result: String? var service = IOIteratorNext(iterator) while service != 0 { var loc: UInt32 = 0 if let ref = IORegistryEntryCreateCFProperty(service, "locationID" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let num = ref as? NSNumber { loc = num.uint32Value } if loc == location, let ref = IORegistryEntryCreateCFProperty(service, "USB Serial Number" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let serial = ref as? String { result = serial } IOObjectRelease(service) if result != nil { break } service = IOIteratorNext(iterator) } return result } let session = AVCaptureDevice.DiscoverySession(deviceTypes: [.external], mediaType: .video, position: .unspecified) for device in session.devices { let uid = device.uniqueID let location = UInt32(truncatingIfNeeded: strtoull(uid, nil, 16) >> 32) let serial = usbSerial(forLocation: location) ?? "N/A" print("\(device.localizedName) uid=\(uid) serial=\(serial)") }
1
0
354
Jul ’26
H.264 MP4 video playback is choppy on iOS 27 Beta 1/2
Environment Device: iPhone (reproducible on multiple devices) OS: iOS 27 Beta 1, Beta 2 Video Format: MP4 (H.264 Main Profile) Playback Method: Apple basic player (HTML5 Video / AVPlayer) Issue We are experiencing video stuttering during playback of a specific MP4 file on iOS 27 Beta 1 and Beta 2. The video plays smoothly on previous iOS versions, but on iOS 27 Beta, playback becomes choppy with noticeable frame drops. Steps to Reproduce Prepare a device running iOS 27 Beta 1 or Beta 2. Open the video URL. https://pdst.mimacstudy.com/daesungmimacfree/CDN/MIMAC/PUBLIC/IPS/2026/P260529018_H.mp4 Start playback. Expected Result The video should play smoothly without visible frame drops. Actual Result The video stutters during playback and appears to drop frames intermittently. Additional Information The issue is consistently reproducible. The affected file is encoded as H.264 Main Profile in an MP4 container. No obvious AVPlayer or system error logs are generated during playback. Has anyone observed similar behavior on iOS 27 Beta, or is there any known change in H.264 decoding behavior that could explain this issue?
2
1
623
Jun ’26
Metadata in Video stripped by Share Sheet / Airdrop
I have an application which records video along with some custom metadata and a chapter track. The resultant video is stored in the Camera Roll. When sharing the video via the Share Sheet or AirDrop, the metadata track is stripped entirely (the chapter markers are preserved) Sharing via AirDrop with the "All Photos Data" option does include the metadata track, as does copying from the device with Image Capture but this is a bad user experience as the user must remember to explicitly select this option, and the filename is lost when sending this way. I have also tried various other approaches (such as encoding my metadata in a subtitle track, which I didn't expect to be stripped as it's an accessibility concern) but it's also removed. Essentially I am looking for a definitive list of things that are not stripped or if there's a way to encode a track in some way to indicate it should be preserved. The metadata is added via AVTimedMetadataGroup containing one AVMutableMetadataItem which has its value as a JSON string. I took a different approach with the Chapter Marker track (mainly because I did it first in a completely different way and didn't rework it when I added the other track). I post-process these after the video is recorded, and add them with addMutableTrack and then addTrackAssociation(to: chapterTrack, type: .chapterList) but I don't think that's the reason the chapter track persists where the custom metadata does not as other tests with video files from other sources containing subtitles etc also had their subtitle data stripped. tl;dr I record videos with metadata that I want to be able to share via Share Sheet and AirDrop, what am I doing wrong?
2
0
1.2k
Jun ’26
ImmersiveMediaRemotePreviewSender — "supportsMVHEVCEncode=0 / Failed to create ▎ immersive video rules" on M3, despite VTIsStereoMVHEVCEncodeSupported() == true
TLS + connectReceiver connect successfully, but the sender fails to negotiate the immersive video stream: VCVideoRuleCollectionsImmersiveVideoMac initSupportedPayloads: Empty supported payload: supportsMVHEVCEncode=0 Failed to create immersive video rules! AVCMediaStreamNegotiator … Failed to init … for mode=15 hardwareSettingsModeFromFeatureListStringType: Unexpected featureListStringType=0 connectReceiver failed … GKVoiceChatServiceErrorDomain 32032 Host: MacBook Pro M3 (Mac15,3), macOS 26/27. VTIsStereoMVHEVCEncodeSupported() returns true, and I set preferredVideoWidth/Height/FrameRate. Is immersive MV-HEVC encode in this API gated by an entitlement, a specific M-series tier (Pro/Max), or a known beta issue? What populates the "immersive video rules" feature list?
0
0
267
Jun ’26
VideoPlayer crashes on Archive build
I have found that following code runs without issue from Xcode, either in Debug or Release mode, yet crashes when running from the binary produced by archiving - i.e. what will be sent to the app store. import SwiftUI import AVKit @main struct tcApp: App { var body: some Scene { WindowGroup { VideoPlayer(player: nil) } } } This is the most stripped down code that shows the issue. One can try and point the VideoPlayer at a file and the same issue will occur. I've attached the crash log: Crash log Please note that this was seen with Xcode 26.2 and MacOS 26.2.
2
0
1.2k
Jun ’26
VisionOS: << FigVideoTargetRemoteXPC >> signalled err=-15562
visionOS 26.5, xcode26.5 - app terminated with exit code 9 then crashed and rebooted the entire device (Apple Vision Pro). I was connected to the Xcode debugger when this happened, and it didn't crash in any of our code. Memory and CPU usage was low at the time. Any idea what could be causing the issue? Some logs: << FigVideoTargetRemoteXPC >> signalled err=-15562 at <>:868 ... Call start on AVKSDockingService before making requests. <<<< FigPlayerInterstitial >>>> signalled err= 18,446,744,073,709,535,945 at <>: 10,773 <<<< FigPlayerInterstitial >>>> signalled err= 18,446,744,073,709,535,945 at <>: 10,773 << FigVideoTargetRemoteXPC >> signalled err=-15562 at <>:868 <<<< PlayerRemoteXPC >>>> signalled err= 18,446,744,073,709,538,756 at <>: 1,538 SessionCore_NotificationHandlers.mm : 73 Server returned an error:. Error Domain=NSOSStatusErrorDomain Code=-50 "Session lookup failed" UserInfo={NSLocalizedDescription=Session lookup failed} <<<< PlayerRemoteXPC >>>> signalled err= 18,446,744,073,709,538,756 at <>: 1,538 ... nw_read_request_report [C 1 ] Receive failed with error " No message available on STREAM " nw_protocol_socket_reset_linger [C1:2] setsockopt SO_LINGER failed 22 Debug session ended with code 9: Terminated due to signal 9 Program ended with exit code: 9 Thanks, bvsdev
1
0
357
Jun ’26
Reference Mode custom presets do not reproduce the same grayscale response as built-in Apple presets
I found an issue with macOS Reference Modes where a recreated custom preset does not match the grayscale response of the original Apple-provided preset, even when all visible settings appear to be identical. For example, when duplicating the built-in Apple Display P3-600 nits Reference Mode preset, the duplicated preset does not produce the same grayscale luminance response as the original system preset. The comparison is performed under the same physical display brightness setting. The difference is not caused by different brightness levels. The native Reference Mode preset and the recreated preset are tested at the same display brightness, but the grayscale response is still different. The same behavior also occurs when manually creating a new Reference Mode preset with equivalent parameters, including using Pure Gamma settings. Even when the gamma value and other visible parameters are matched, the grayscale transfer function in the shadow region does not match the original Apple preset. The difference can be observed using grayscale test patterns, including: BarsAndBlack_16bit.TIFF CT ColorBar test pattern With these test images, the recreated preset shows lifted dark tones compared with the original Apple Display P3-600 nits preset. The darker grayscale steps become brighter, indicating that the EOTF/grayscale response is not identical between the built-in preset and the recreated preset. This behavior can be reproduced using the built-in macOS Preview application. Opening the same test image and switching between the native Reference Mode preset and the recreated preset shows differences in the black level and shadow grayscale response. The issue can be reproduced on both macOS 26.4 and macOS 15. Environment: macOS: 26.4 (also reproducible on macOS 15) Mac: 14-inch MacBook Pro Display: Built-in XDR Display Reference Mode tested: Apple Display P3-600 nits The main question is: When there is a difference between the built-in Apple Reference Mode preset and a recreated preset with the same visible parameters, which one represents the intended and accurate gamma/EOTF response? Specifically: Is the built-in Apple Display P3-600 nits Reference Mode using additional internal calibration data or hidden parameters that are not exposed in the Reference Mode configuration UI? Is the recreated preset actually applying the requested gamma curve correctly, while the Apple preset includes additional processing? Or is the Apple built-in preset the accurate reference implementation, and the recreated preset cannot reproduce it because some internal display calibration information is unavailable? Is there a documented way to create a custom Reference Mode preset that exactly matches the grayscale response of an Apple system preset? Thank you.
1
0
329
Jun ’26
Supporting custom headers in CMCD
Today we are on-boarded to using CMCD data to allow us to get more diagnostic data of our streaming. We would like to have the ability to upload our own custom headers, this is supported on other players, but not supported on AVPlayer. The workaround today that works is adding in custom query parameters then querying based on that, but we would like support explicitly in the headers.
2
1
386
Jun ’26
How many concurrent VTCompressionSession / VTDecompressionSession can an app run, and can the limit be queried?
I'm batch-transcoding a library of clips into downscaled editing proxies. If I kick off two hardware transcodes at once, the encoder reliably falls over, so right now I run everything serially: each clip gets fully decoded, encoded, and muxed before the next one starts. It works, but it's slow, and the decode and encode hardware are mostly idle waiting on each other. A few things I can't pin down from the docs: Is there an actual ceiling on how many VTCompressionSession / VTDecompressionSession instances can be live at once, and does it depend on the device, the codec, or the resolution? Can I query that ceiling at runtime? I'd rather size my concurrency up front than find it by crashing. Decode and encode are separate hardware blocks, so can I safely run a decode session for one clip while the previous clip is still encoding, or does VideoToolbox serialize them anyway? When I do go over the limit, what should I be checking so I can back off cleanly? Right now I just get a crash instead of an error I can catch. Anything that gets me off the fully-serial pipeline would help. Thank you
5
0
509
Jun ’26
kVTCompressionPropertyKey_AverageBitRate seems to be broken in iOS 27 Beta
The set bitrate is not respected when kVTCompressionPropertyKey_AverageBitRate is used. constant and variable bitrates seems to work, only average that is broken. All three modes works in iOS 26.
Replies
4
Boosts
0
Views
1.2k
Activity
12h
Custom AVVideoCompositing on a composition-backed AVPlayerItem fails with AVErrorUnknown Xcode 27 beta 2 / beta 3
Trivial pass-through compositor fails on Xcode 27 (beta 2, beta 3); error code -11800 underlying error -12784. Repro included https://github.com/BugorBN/avplayer-custom-compositor-repro It works well on Xcode26 and lower
Replies
1
Boosts
2
Views
255
Activity
1d
Mac Os 27, can't turn off live subtitles and code to turn it off from app
So, in macos golden gate 27, there is this new live subtitles that happens in every video that i can't even turn off? (live captions is off) and also is there anyway from code we can turn this feature off, because making a background app, it exists whenever, and i can't seem to find a way to disable it from coding and the app.
Replies
1
Boosts
0
Views
655
Activity
4d
Why does an edited 4K 60 FPS video become significantly smaller than the original when exported from the Photos library?
I'm observing an interesting behavior on iOS when uploading edited videos from the Photos library. Scenario Device: iPhone Video: 4K, 60 FPS Original video size (Photos app): 660 MB Uploaded original asset: 660 MB After applying a simple edit (e.g., a filter) in the Photos app: Photos app still shows the edited video. When my app uploads the current/edited asset, the uploaded file size becomes 167 MB. So the edited version is approximately 75% smaller than the original (660 MB → 167 MB), even though the duration appears unchanged. Questions Is this expected behavior for edited videos in the Photos library? Does iOS automatically re-encode edited videos using a lower bitrate or a different codec (e.g., HEVC) when generating the current rendition? Does the Photos app continue to display the size of the original asset rather than the size of the edited rendition? I'm aware that PhotoKit allows retrieving both the original and the current (edited) versions of a PHAsset. In this case, I'm intentionally retrieving the current version, and this behavior is observed only for the edited asset.
Replies
1
Boosts
0
Views
193
Activity
5d
iOS 27 beta: Opening Notification Center pauses AVPlayer playback
Since iOS 27 beta we are seeing a behavior change in our video streaming app and I would like to know whether others can reproduce it. Behavior on iOS 27 beta: Fully opening the Notification Center pauses playback. Audio continues for about 5 more seconds, then the app is suspended. Closing the Notification Center leaves the player paused. On iOS 26 the same build keeps playing in this situation. Setup: AVQueuePlayer playing video with audio, not muted audiovisualBackgroundPlaybackPolicy = .automatic (default) AVAudioSession category .playback, UIBackgroundModes: audio entitlement AVPictureInPictureController attached with canStartPictureInPictureAutomaticallyFromInline = true Filed as FB23893965 Questions: Can anyone reproduce this on iOS 27 beta? Is this intentional or a regression?
Replies
0
Boosts
2
Views
193
Activity
1w
Why does retrieving the `PixelBuffer` of only one eye improve performance significantly on 2020 Mac mini?
Hi all! I'm maintaining a 3D video player, it's great to see we've developed MV-HEVC packed with great features that media industry love to use. This player uses macOS AV frameworks to decode MV-HEVC and plays time-interleaving signal on capable devices, such as DLP-Link projectors, 3D vision glasses syncing devices, etc. Previously, the player output was flickering, unstable when playing MV-HEVC, and I thought it was due to M1 didn't have hardware decoder for it, or 4K Dolby Vision decoding was too demanding for my Mac, but out of luck, I tried retrieving only 1 eye for each frame output during the DisplayLink call, and the flickering is gone. At least that's what I've seen with a 100Hz screen while testing. Why is the performance improvement so significant? And is there other ways I can improve the performance, and perhaps the energy consumption? The link to the change I've committed
Replies
0
Boosts
0
Views
214
Activity
2w
AVPlayerController. Internal constraints conflicts on tvOS.
I’m getting Auto Layout constraint conflict warnings related to AVPlayerController in my tvOS project. This issue can be reproduced in an empty tvOS project either by simply using an AVPlayerViewController as a initial view controller or by presenting it. tvOS 26.2 Simple empty project with only one controller: import UIKit import AVKit class PlayerViewController: AVPlayerViewController { override func viewDidLoad() { super.viewDidLoad() } } After presenting that view controller, the following Auto Layout constraint conflict warnings appear in the console: Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. ( "<NSLayoutConstraint:0x60000212f5c0 UIStackView:0x103222520.width >= 217 (active)>", "<NSLayoutConstraint:0x60000212f610 H:|-(>=95)-[UIStackView:0x103222520] (active, names: '|':UIView:0x103216630 )>", "<NSLayoutConstraint:0x60000212f660 UIStackView:0x103222520.trailing == UIView:0x103216630.trailing - 95 (active)>", "<NSLayoutConstraint:0x60000212f7a0 H:|-(0)-[UIView:0x103216630] (active, names: '|':_AVFocusContainerView:0x10333aea0 )>", "<NSLayoutConstraint:0x60000212f7f0 UIView:0x103216630.trailing == _AVFocusContainerView:0x10333aea0.trailing (active)>", "<NSLayoutConstraint:0x6000021309b0 '_UITemporaryLayoutWidth' _AVFocusContainerView:0x10333aea0.width == 0 (active)>" ) Will attempt to recover by breaking constraint <NSLayoutConstraint:0x60000212f5c0 UIStackView:0x103222520.width >= 217 (active)> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger. The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in <UIKitCore/UIView.h> may also be helpful. How can I fix this issue? Thanks.
Replies
2
Boosts
0
Views
245
Activity
2w
Is it safe to use undocumented VT encoder profiles for 4:4:4 encoding?
While working with VTCompressionSession, I noticed some profiles that were returned by the VTSessionCopySupportedPropertyDictionary but were not documented in header files (other than appearing in the VideoToolbox.tbd file). Specifically: kVTProfileLevel_HEVC_Main44410_AutoLevel kVTProfileLevel_HEVC_Main444_AutoLevel kVTProfileLevel_H264_High444Predictive_AutoLevel If I manually define these, they do seem to work OK (macOS/Xcode 26.4). I expect the answer will be that they are undocumented for a reason, but hasn't 4:4:4 encode been a feature for a while?
Replies
0
Boosts
0
Views
198
Activity
3w
iOS 26.4 regression: The `.pauses` audiovisual background playback policy does not pause video playback anymore when backgrounding the app
Starting with iOS 26.4 and the iOS 26.4 SDK, the .pauses audiovisual background playback policy is not correctly applied anymore to an AVPlayer having an attached video layer displayed on screen. This means that, when backgrounding a video-playing app (without Picture in Picture support) or locking the device, playback is not paused automatically by the system anymore. This issue affects the Apple TV application as well. We have filed FB22488151 with more information.
Replies
2
Boosts
0
Views
788
Activity
3w
AVQueuePlayer unexpectedly performs network requests during offline HLS playback after several queued episode transitions
Hello, We are investigating an issue with offline HLS playback using AVQueuePlayer and would like to know whether anyone else has experienced similar behavior. Issue We download HLS content using AVAssetDownloadURLSession and play it offline using AVQueuePlayer. For some titles (but not all), after several consecutive episode transitions, the player unexpectedly attempts a network request while the next episode is already queued and the current episode has approximately 60 seconds remaining. If the device is offline, playback fails with: NSURLErrorDomain Code = -1009 and the next episode never starts. Characteristics The issue only affects certain titles. It is fully reproducible for affected titles. For example, if it occurs between Episodes 5 and 6 after starting playback from Episode 1, it always occurs at the same point when replaying from Episode 1. If playback starts directly from Episode 5, the issue does not occur. The issue only occurs when using AVQueuePlayer. Replacing the current item (removeAllItems() + replaceCurrentItem(with:)) avoids the issue, although this is unfortunately not a viable workaround because it breaks our Picture in Picture episode transition behavior. We compared the downloaded packages (boot.xml, Master Playlist, and Stream configuration) between affected and unaffected titles, but so far have not identified any meaningful structural differences that explain the behavior. Questions Has anyone experienced similar behavior with: offline HLS (.movpkg) AVQueuePlayer unexpected network requests during queued playback NSURLErrorDomain Code=-1009 even though the content is downloaded for offline playback If anyone has seen a similar issue or has any information, observations, or suggestions for further investigation, I would greatly appreciate hearing from you. For reference, I have already submitted this issue through Feedback Assistant. Feedback ID: FB23487817 Thank you in advance for any information.
Replies
2
Boosts
0
Views
360
Activity
3w
AVCaptureDevice.uniqueID for UVC video devices is unstable - bug or overstated documentation?
The documentation for AVCaptureDevice.uniqueID states the following: Capture devices have a unique identifier that persists on one system across device connections and disconnections, application restarts, and reboots of the system itself. You can store the value returned by this property to recall or track the status of a specific device in the future. For UVC capture devices this documentation does not hold. The video uniqueID is a hex string of the form 0x, and the identifying half is the locationID (bus number plus port path). Which identifies a port, not a device. I ran a suite of tests with three identical Elgato 4K X capture cards connected to a Mac Studio w/ M3 Ultra running macOS 26.5.2, and reproduced my findings on a MacBook w/ M3 Pro (same macOS version). See the script at the bottom of the post for how uniqueId & USB serial number are being retrieved. 1. The uniqueID follows the port. Swapping two cards between two built-in ports swaps their uniqueIDs: # Before swap. 4K X uid=0x2000000fd9009b serial=A7SNB50424UBQI 4K X uid=0x12000000fd9009b serial=A7SNB504219J0R # After swapping the cards between the same two ports. 4K X uid=0x2000000fd9009b serial=A7SNB504219J0R 4K X uid=0x12000000fd9009b serial=A7SNB50424UBQI An app that stored 0x2000000fd9009b to recall a specific capture card now silently opens another. 2. A reboot alone can swap uniqueIDs. External USB controllers (here, PCIe USB cards in two Thunderbolt enclosures) can race for bus numbers at boot, so with every cable left in place, a reboot swapped two of the cards: # Before reboot. 4K X uid=0x262000000fd9009b serial=A7SNB504219J0R 4K X uid=0x252000000fd9009b serial=A7SNB50423R73R # After reboot, no cables touched. 4K X uid=0x262000000fd9009b serial=A7SNB50423R73R 4K X uid=0x252000000fd9009b serial=A7SNB504219J0R This behavior is intermittent, a second reboot changed nothing, but a third caused another swap. Cards left alone in built-in ports retain their uniqueIDs across reboots in my testing; the failure requires dynamically enumerated external USB controllers. 3. Even the product ID tail can drift. One unit intermittently enumerates with idProduct 0x009c instead of 0x009b, same port (USB PCIe card in a Thunderbolt enclosure), cables untouched: # Before reboot. 4K X uid=0x222000000fd9009b serial=A7SNB50424UBQI # After reboot. 4K X uid=0x222000000fd9009c serial=A7SNB50424UBQI IOKit and AVFoundation agree each boot... So the change is upstream of both? I'm uncertain where to place blame for this specific issue (UVC device or macOS). Audio on the same physical units is unaffected. The audio uniqueID (AppleUSBAudioEngine:...:<serial>:...) embeds the USB serial and stayed stable through every test. So AVCaptureDevice can provide a stable per-device identifier, just not for UVC video devices. Questions: Is this a bug, or is the documentation overstating the persistence guarantee for USB video devices? What is the supported way to identify a specific physical UVC video device across reboots and port changes? The USB serial number is stable and is what I've fallen back on via IOKit, but there is no documented AVFoundation API to retrieve USB serial number from a UVC video AVCaptureDevice. Related: thread 803759, where the locationID-derived format is described. Script used for all output above (swift ./list-uvc.swift): import AVFoundation import IOKit func usbSerial(forLocation location: UInt32) -> String? { var iterator: io_iterator_t = 0 guard IOServiceGetMatchingServices(kIOMainPortDefault, IOServiceMatching("IOUSBHostDevice"), &iterator) == KERN_SUCCESS else { return nil } defer { IOObjectRelease(iterator) } var result: String? var service = IOIteratorNext(iterator) while service != 0 { var loc: UInt32 = 0 if let ref = IORegistryEntryCreateCFProperty(service, "locationID" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let num = ref as? NSNumber { loc = num.uint32Value } if loc == location, let ref = IORegistryEntryCreateCFProperty(service, "USB Serial Number" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let serial = ref as? String { result = serial } IOObjectRelease(service) if result != nil { break } service = IOIteratorNext(iterator) } return result } let session = AVCaptureDevice.DiscoverySession(deviceTypes: [.external], mediaType: .video, position: .unspecified) for device in session.devices { let uid = device.uniqueID let location = UInt32(truncatingIfNeeded: strtoull(uid, nil, 16) >> 32) let serial = usbSerial(forLocation: location) ?? "N/A" print("\(device.localizedName) uid=\(uid) serial=\(serial)") }
Replies
1
Boosts
0
Views
308
Activity
4w
AVCaptureDevice.uniqueID for UVC devices is unstable - bug or overstated documentation?
The documentation for AVCaptureDevice.uniqueID states the following: Capture devices have a unique identifier that persists on one system across device connections and disconnections, application restarts, and reboots of the system itself. You can store the value returned by this property to recall or track the status of a specific device in the future. For UVC capture devices this documentation does not hold. The video uniqueID is a hex string of the form 0x<locationID><vendorID><productID>, and the identifying half is the locationID (bus number plus port path). Which identifies a port, not a device. I ran a suite of tests with three identical Elgato 4K X capture cards connected to a Mac Studio w/ M3 Ultra running macOS 26.5.2, and reproduced my findings on a MacBook w/ M3 Pro (same macOS version). See the script at the bottom of the post for how uniqueId & USB serial number are being retrieved. 1. The uniqueID follows the port. Swapping two cards between two built-in ports swaps their uniqueIDs: # Before swap. 4K X uid=0x2000000fd9009b serial=A7SNB50424UBQI 4K X uid=0x12000000fd9009b serial=A7SNB504219J0R # After swapping the cards between the same two ports. 4K X uid=0x2000000fd9009b serial=A7SNB504219J0R 4K X uid=0x12000000fd9009b serial=A7SNB50424UBQI An app that stored 0x2000000fd9009b to recall a specific capture card now silently opens another. 2. A reboot alone can swap uniqueIDs. External USB controllers (here, PCIe USB cards in two Thunderbolt enclosures) can race for bus numbers at boot, so with every cable left in place, a reboot swapped two of the cards: # Before reboot. 4K X uid=0x262000000fd9009b serial=A7SNB504219J0R 4K X uid=0x252000000fd9009b serial=A7SNB50423R73R # After reboot, no cables touched. 4K X uid=0x262000000fd9009b serial=A7SNB50423R73R 4K X uid=0x252000000fd9009b serial=A7SNB504219J0R This behavior is intermittent, a second reboot changed nothing, but a third caused another swap. Cards left alone in built-in ports retain their uniqueIDs across reboots in my testing; the failure requires dynamically enumerated external USB controllers. 3. Even the product ID tail can drift. One unit intermittently enumerates with idProduct 0x009c instead of 0x009b, same port (USB PCIe card in a Thunderbolt enclosure), cables untouched: # Before reboot. 4K X uid=0x222000000fd9009b serial=A7SNB50424UBQI # After reboot. 4K X uid=0x222000000fd9009c serial=A7SNB50424UBQI IOKit and AVFoundation agree each boot... So the change is upstream of both? I'm uncertain where to place blame for this specific issue (UVC device or macOS). Audio on the same physical units is unaffected. The audio uniqueID (AppleUSBAudioEngine:...:<serial>:...) embeds the USB serial and stayed stable through every test. So AVCaptureDevice can provide a stable per-device identifier, just not for UVC video devices. Questions: Is this a bug, or is the documentation overstating the persistence guarantee for USB video devices? What is the supported way to identify a specific physical UVC video device across reboots and port changes? The USB serial number is stable and is what I've fallen back on via IOKit, but there is no documented AVFoundation API to retrieve USB serial number from a UVC video AVCaptureDevice. Related: thread 803759, where the locationID-derived format is described. Script used for all output above (swift ./list-uvc.swift): import AVFoundation import IOKit func usbSerial(forLocation location: UInt32) -> String? { var iterator: io_iterator_t = 0 guard IOServiceGetMatchingServices(kIOMainPortDefault, IOServiceMatching("IOUSBHostDevice"), &iterator) == KERN_SUCCESS else { return nil } defer { IOObjectRelease(iterator) } var result: String? var service = IOIteratorNext(iterator) while service != 0 { var loc: UInt32 = 0 if let ref = IORegistryEntryCreateCFProperty(service, "locationID" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let num = ref as? NSNumber { loc = num.uint32Value } if loc == location, let ref = IORegistryEntryCreateCFProperty(service, "USB Serial Number" as CFString, kCFAllocatorDefault, 0)?.takeRetainedValue(), let serial = ref as? String { result = serial } IOObjectRelease(service) if result != nil { break } service = IOIteratorNext(iterator) } return result } let session = AVCaptureDevice.DiscoverySession(deviceTypes: [.external], mediaType: .video, position: .unspecified) for device in session.devices { let uid = device.uniqueID let location = UInt32(truncatingIfNeeded: strtoull(uid, nil, 16) >> 32) let serial = usbSerial(forLocation: location) ?? "N/A" print("\(device.localizedName) uid=\(uid) serial=\(serial)") }
Replies
1
Boosts
0
Views
354
Activity
Jul ’26
H.264 MP4 video playback is choppy on iOS 27 Beta 1/2
Environment Device: iPhone (reproducible on multiple devices) OS: iOS 27 Beta 1, Beta 2 Video Format: MP4 (H.264 Main Profile) Playback Method: Apple basic player (HTML5 Video / AVPlayer) Issue We are experiencing video stuttering during playback of a specific MP4 file on iOS 27 Beta 1 and Beta 2. The video plays smoothly on previous iOS versions, but on iOS 27 Beta, playback becomes choppy with noticeable frame drops. Steps to Reproduce Prepare a device running iOS 27 Beta 1 or Beta 2. Open the video URL. https://pdst.mimacstudy.com/daesungmimacfree/CDN/MIMAC/PUBLIC/IPS/2026/P260529018_H.mp4 Start playback. Expected Result The video should play smoothly without visible frame drops. Actual Result The video stutters during playback and appears to drop frames intermittently. Additional Information The issue is consistently reproducible. The affected file is encoded as H.264 Main Profile in an MP4 container. No obvious AVPlayer or system error logs are generated during playback. Has anyone observed similar behavior on iOS 27 Beta, or is there any known change in H.264 decoding behavior that could explain this issue?
Replies
2
Boosts
1
Views
623
Activity
Jun ’26
Metadata in Video stripped by Share Sheet / Airdrop
I have an application which records video along with some custom metadata and a chapter track. The resultant video is stored in the Camera Roll. When sharing the video via the Share Sheet or AirDrop, the metadata track is stripped entirely (the chapter markers are preserved) Sharing via AirDrop with the "All Photos Data" option does include the metadata track, as does copying from the device with Image Capture but this is a bad user experience as the user must remember to explicitly select this option, and the filename is lost when sending this way. I have also tried various other approaches (such as encoding my metadata in a subtitle track, which I didn't expect to be stripped as it's an accessibility concern) but it's also removed. Essentially I am looking for a definitive list of things that are not stripped or if there's a way to encode a track in some way to indicate it should be preserved. The metadata is added via AVTimedMetadataGroup containing one AVMutableMetadataItem which has its value as a JSON string. I took a different approach with the Chapter Marker track (mainly because I did it first in a completely different way and didn't rework it when I added the other track). I post-process these after the video is recorded, and add them with addMutableTrack and then addTrackAssociation(to: chapterTrack, type: .chapterList) but I don't think that's the reason the chapter track persists where the custom metadata does not as other tests with video files from other sources containing subtitles etc also had their subtitle data stripped. tl;dr I record videos with metadata that I want to be able to share via Share Sheet and AirDrop, what am I doing wrong?
Replies
2
Boosts
0
Views
1.2k
Activity
Jun ’26
ImmersiveMediaRemotePreviewSender — "supportsMVHEVCEncode=0 / Failed to create ▎ immersive video rules" on M3, despite VTIsStereoMVHEVCEncodeSupported() == true
TLS + connectReceiver connect successfully, but the sender fails to negotiate the immersive video stream: VCVideoRuleCollectionsImmersiveVideoMac initSupportedPayloads: Empty supported payload: supportsMVHEVCEncode=0 Failed to create immersive video rules! AVCMediaStreamNegotiator … Failed to init … for mode=15 hardwareSettingsModeFromFeatureListStringType: Unexpected featureListStringType=0 connectReceiver failed … GKVoiceChatServiceErrorDomain 32032 Host: MacBook Pro M3 (Mac15,3), macOS 26/27. VTIsStereoMVHEVCEncodeSupported() returns true, and I set preferredVideoWidth/Height/FrameRate. Is immersive MV-HEVC encode in this API gated by an entitlement, a specific M-series tier (Pro/Max), or a known beta issue? What populates the "immersive video rules" feature list?
Replies
0
Boosts
0
Views
267
Activity
Jun ’26
VideoPlayer crashes on Archive build
I have found that following code runs without issue from Xcode, either in Debug or Release mode, yet crashes when running from the binary produced by archiving - i.e. what will be sent to the app store. import SwiftUI import AVKit @main struct tcApp: App { var body: some Scene { WindowGroup { VideoPlayer(player: nil) } } } This is the most stripped down code that shows the issue. One can try and point the VideoPlayer at a file and the same issue will occur. I've attached the crash log: Crash log Please note that this was seen with Xcode 26.2 and MacOS 26.2.
Replies
2
Boosts
0
Views
1.2k
Activity
Jun ’26
VisionOS: << FigVideoTargetRemoteXPC >> signalled err=-15562
visionOS 26.5, xcode26.5 - app terminated with exit code 9 then crashed and rebooted the entire device (Apple Vision Pro). I was connected to the Xcode debugger when this happened, and it didn't crash in any of our code. Memory and CPU usage was low at the time. Any idea what could be causing the issue? Some logs: << FigVideoTargetRemoteXPC >> signalled err=-15562 at <>:868 ... Call start on AVKSDockingService before making requests. <<<< FigPlayerInterstitial >>>> signalled err= 18,446,744,073,709,535,945 at <>: 10,773 <<<< FigPlayerInterstitial >>>> signalled err= 18,446,744,073,709,535,945 at <>: 10,773 << FigVideoTargetRemoteXPC >> signalled err=-15562 at <>:868 <<<< PlayerRemoteXPC >>>> signalled err= 18,446,744,073,709,538,756 at <>: 1,538 SessionCore_NotificationHandlers.mm : 73 Server returned an error:. Error Domain=NSOSStatusErrorDomain Code=-50 "Session lookup failed" UserInfo={NSLocalizedDescription=Session lookup failed} <<<< PlayerRemoteXPC >>>> signalled err= 18,446,744,073,709,538,756 at <>: 1,538 ... nw_read_request_report [C 1 ] Receive failed with error " No message available on STREAM " nw_protocol_socket_reset_linger [C1:2] setsockopt SO_LINGER failed 22 Debug session ended with code 9: Terminated due to signal 9 Program ended with exit code: 9 Thanks, bvsdev
Replies
1
Boosts
0
Views
357
Activity
Jun ’26
Reference Mode custom presets do not reproduce the same grayscale response as built-in Apple presets
I found an issue with macOS Reference Modes where a recreated custom preset does not match the grayscale response of the original Apple-provided preset, even when all visible settings appear to be identical. For example, when duplicating the built-in Apple Display P3-600 nits Reference Mode preset, the duplicated preset does not produce the same grayscale luminance response as the original system preset. The comparison is performed under the same physical display brightness setting. The difference is not caused by different brightness levels. The native Reference Mode preset and the recreated preset are tested at the same display brightness, but the grayscale response is still different. The same behavior also occurs when manually creating a new Reference Mode preset with equivalent parameters, including using Pure Gamma settings. Even when the gamma value and other visible parameters are matched, the grayscale transfer function in the shadow region does not match the original Apple preset. The difference can be observed using grayscale test patterns, including: BarsAndBlack_16bit.TIFF CT ColorBar test pattern With these test images, the recreated preset shows lifted dark tones compared with the original Apple Display P3-600 nits preset. The darker grayscale steps become brighter, indicating that the EOTF/grayscale response is not identical between the built-in preset and the recreated preset. This behavior can be reproduced using the built-in macOS Preview application. Opening the same test image and switching between the native Reference Mode preset and the recreated preset shows differences in the black level and shadow grayscale response. The issue can be reproduced on both macOS 26.4 and macOS 15. Environment: macOS: 26.4 (also reproducible on macOS 15) Mac: 14-inch MacBook Pro Display: Built-in XDR Display Reference Mode tested: Apple Display P3-600 nits The main question is: When there is a difference between the built-in Apple Reference Mode preset and a recreated preset with the same visible parameters, which one represents the intended and accurate gamma/EOTF response? Specifically: Is the built-in Apple Display P3-600 nits Reference Mode using additional internal calibration data or hidden parameters that are not exposed in the Reference Mode configuration UI? Is the recreated preset actually applying the requested gamma curve correctly, while the Apple preset includes additional processing? Or is the Apple built-in preset the accurate reference implementation, and the recreated preset cannot reproduce it because some internal display calibration information is unavailable? Is there a documented way to create a custom Reference Mode preset that exactly matches the grayscale response of an Apple system preset? Thank you.
Replies
1
Boosts
0
Views
329
Activity
Jun ’26
Supporting custom headers in CMCD
Today we are on-boarded to using CMCD data to allow us to get more diagnostic data of our streaming. We would like to have the ability to upload our own custom headers, this is supported on other players, but not supported on AVPlayer. The workaround today that works is adding in custom query parameters then querying based on that, but we would like support explicitly in the headers.
Replies
2
Boosts
1
Views
386
Activity
Jun ’26
How many concurrent VTCompressionSession / VTDecompressionSession can an app run, and can the limit be queried?
I'm batch-transcoding a library of clips into downscaled editing proxies. If I kick off two hardware transcodes at once, the encoder reliably falls over, so right now I run everything serially: each clip gets fully decoded, encoded, and muxed before the next one starts. It works, but it's slow, and the decode and encode hardware are mostly idle waiting on each other. A few things I can't pin down from the docs: Is there an actual ceiling on how many VTCompressionSession / VTDecompressionSession instances can be live at once, and does it depend on the device, the codec, or the resolution? Can I query that ceiling at runtime? I'd rather size my concurrency up front than find it by crashing. Decode and encode are separate hardware blocks, so can I safely run a decode session for one clip while the previous clip is still encoding, or does VideoToolbox serialize them anyway? When I do go over the limit, what should I be checking so I can back off cleanly? Right now I just get a crash instead of an error I can catch. Anything that gets me off the fully-serial pipeline would help. Thank you
Replies
5
Boosts
0
Views
509
Activity
Jun ’26