Hi, I’ve identified a discrepancy between the FairPlay Streaming SPC v3 documentation and the provided Swift reference implementation regarding the SPC payload length field. Documentation states: The SPC V3 structure defines: SPC payload length: 4 bytes However, in Apple’s Swift sample implementation: // Move local offset by 12 to adjust for padding localOffset += 12 spcContainer.spcDataSize = Int(try readBigEndianU32(spc, localOffset)) This indicates: A 16-byte field (12 bytes padding + 4-byte length) This behavior also matches the SPC sample provided in the FairPlay Streaming SDK (sample_spc_v3.b64 ). 00000003 // spc version 00000000 // reserved .... 00000000000000000000000000000f40 // spc payload length (16 bytes) Could you please confirm the correct implementation? Thanks

Hi, I'm currently experiencing issues with HLS streams created by FFmpeg running on Safari. When I pass the stream to the mediastreamvalidator tool and then run hlsreport on the output, I get a critical error reported: Media Entry discontinuity value does not match previous playlist for MEDIA-SEQUENCE 1 If I let the stream finish (it's a live stream from an IoT device) and then perform the stream validation again I no longer receive the critical error. My assumption is that this critical error is contributing to the HLS stall on iOS. I have also noticed that if I let the stream continue and then re-load the video control in Safari the stream starts Is there a resource with explanations or remediation paths relevant to the possible output of the hlsreport? My m3u8 output looks like this (I have redacted the server host) #EXTM3U #EXT-X-VERSION:6 #EXT-X-TARGETDURATION:2 #EXT-X-MEDIA-SEQUENCE:1 #EXT-X-PLAYLIST-TYPE:EVENT #EXT-X-INDEPENDENT-SEGMENTS #EXT-X-DISCONTINUITY #EXTINF:2.000000, https://redacted.com/segment-00001.ts #EXTINF:2.000011, https://redacted.com/segment-00002.ts #EXTINF:2.000011, https://redacted.com/segment-00003.ts #EXTINF:2.000011, https://redacted.com/segment-00004.ts #EXTINF:2.000011, #EXT-X-ENDLIST Thanks for any advice or guidance possible - if I can provide isolated code snippets I will do. Andy

We've discovered a regression in iOS 26 where AVMutableComposition silently drops audio when the source asset is streamed over HTTP/2. The same file served over HTTP/1.1 plays audio correctly through the same composition code. Direct AVPlayer playback (without composition) works fine on HTTP/2. This did not occur on iOS 18.x. It happens on physical devices only. It does not reproduce on a simulator or on macOS. Tested conditions (same MP4 file, different CDNs): CloudFront (HTTP/2) + Composition → ❌ Audio silent Cloudflare (HTTP/2) + Composition → ❌ Audio silent Akamai (HTTP/1.1) + Composition → ✅ Audio works Apple TS (HTTP/1.1) + Composition → ✅ Audio works Downloaded locally, then composed → ✅ Audio works Direct playback, no composition (HTTP/2) → ✅ Audio works The CloudFront and Akamai URLs serve the identical file — same S3 object, different CDN edge. CDN vendor doesn't matter; any HTTP/2 source triggers it. Minimal reproduction: let asset = AVURLAsset(url: http2URL) let videoTrack = try await asset.loadTracks(withMediaType: .video).first! let audioTrack = try await asset.loadTracks(withMediaType: .audio).first! let duration = try await asset.load(.duration) let composition = AVMutableComposition() let fullRange = CMTimeRange(start: .zero, end: duration) let compVideo = composition.addMutableTrack(withMediaType: .video, preferredTrackID: kCMPersistentTrackID_Invalid)! try compVideo.insertTimeRange(fullRange, of: videoTrack, at: .zero) let compAudio = composition.addMutableTrack(withMediaType: .audio, preferredTrackID: kCMPersistentTrackID_Invalid)! try compAudio.insertTimeRange(fullRange, of: audioTrack, at: .zero) let item = AVPlayerItem(asset: composition.copy() as! AVComposition) player.replaceCurrentItem(with: item) player.play() // Video plays, audio goes silent after a while Playing the same asset directly works fine: player.replaceCurrentItem(with: AVPlayerItem(asset: asset)) player.play() // Both video and audio work Filed as FB22696516 Sample project: https://github.com/karlingen/AVCompositionBug

USB cameras, microphones, HDMI capture cards, and audio interfaces are supposed to "just work" on macOS. In reality, it's often difficult to quickly access or monitor them without opening large and complicated software. Sometimes you simply want to see whether a USB camera is active. Sometimes you want to check an HDMI source connected through a capture card. And in other cases, you may want to use a Mac mini without a dedicated monitor by viewing its HDMI output through a USB capture device directly on another Mac. macOS supports many modern USB AV devices out of the box, but it surprisingly lacks a simple built-in utility for live monitoring and recording. Most users end up using oversized streaming or editing applications just to preview a video signal or monitor audio input. That becomes especially noticeable with: USB webcams HDMI capture adapters USB microphones audio interfaces secondary computers headless Mac mini setups A lightweight monitor utility is often much more practical when you only need real-time access to a device, want to record a stream, or quickly switch between multiple AV inputs. That's one of the reasons I built AV Monitor Pro  -  a native macOS app designed for monitoring and recording connected audio/video devices in real time. It can preview USB cameras, capture cards, microphones, and HDMI sources with minimal setup, and it's especially useful for workflows like running a Mac mini without a monitor, monitoring external devices, or recording live AV input directly on macOS.

Currently we are building a service based on Fairplay SDK version 26.0. Currently our solution is using version 4.5.4. When we run the below request to get version we get proper response curl http://xx.xx.xx.xx:8080/fps/v Response - V26.0 Our client applications call below two APIs https://GW_HOST:8080/fairplay_cert https://GW_HOST:8080/fairplay_license Within the cert API call, we are returning the fairplay public certificate. Currently we are trying to use the test certificate provided along with Fairplay SDK (test_fps_certificate_v26.bin) Then within the fairplay_license API call, we are trying to reach fairplay service based on Fairplay SDK v26 We are seeing some issues with below request(attaching the request json payload) curl -v -X POST \ -H "Content-Type: application/json" \ -d @SDKValidation.json \ http://xx.xx.xx.xx:8080/fps SDKValidation.json We are getting "Empty response from server" When we checked the apache error logs in the file "/etc/httpd/logs/error_log" we see some exception. We are sharing the traces in a file (ApacheErrorLogs.txt). ApacheErrorLogs.txt Also if we use old pblic key used with version 4.5.4, we are getting another error from service. {"fairplay-streaming-response":{"create-ckc":[{"id":1,"status":-42605}]}} Can you please help us with the reason of this failure?

Is there a way to attach a MusicUnderstandingSession to a MusicKit stream or audiofile?

When we try to use AVPictureInPictureController with a AVSampleBufferDisplayLayer on tvOS 15 through tvOS 26 isPictureInPicturePossible never becomes true. The code works great on iOS, but it has never worked on tvOS. You can check this out for a repro: https://github.com/jazzychad/PiPBugDemo Feedbacks: FB9751461, FB14158567, FB14037110 DTS Case: 7999337

Hi, We currently deliver HDR10+ content within a composite HLS stream where Dolby Vision is signaled as a supplemental codec alongside HDR10+. Our testing on Apple TV 4K (3rd generation) indicates that playback succeeds, but we have not found a reliable way to determine whether playback is occurring in Dolby Vision or HDR10+ mode when connected to a display that supports both formats. We have also verified that the same stream plays correctly on displays that support HDR10+ but do not support Dolby Vision. However, on displays that support both HDR10+ and Dolby Vision, we are unable to determine which dynamic range format AVPlayer ultimately selects. Is there a recommended Apple API or mechanism to determine whether AVPlayer is rendering content as HDR10+, Dolby Vision, or another HDR format at runtime? For reference, below is an example variant from our master playlist: #EXT-X-STREAM-INF:BANDWIDTH=2851276,AVERAGE-BANDWIDTH=2030750,CODECS="hvc1.2.4.L90.90,mp4a.40.2",SUPPLEMENTAL-CODECS="dvh1.08.01/dv1p,hvc1.2.4.L90.90/cdm4",RESOLUTION=854x480,FRAME-RATE=24,VIDEO-RANGE=PQ,HDCP-LEVEL=TYPE-1,CHARACTERISTICS="com.dss.cbcs.hdr.hd",AUDIO="aac-128k",SUBTITLES="sub-main" Specifically, we would like to understand: How AVPlayer chooses between Dolby Vision and HDR10+ when both are available in the same variant. Whether there is a supported way to determine the selected HDR format during playback. Whether any other APIs expose this information. Any guidance would be greatly appreciated. Thank you.

To reduce latency in our live HLS service, we are experimenting with short segment durations (1–2 seconds). We have noticed that ABR switching occurs more frequently than expected. Looking at the console logs, variants appear to enter and leave what is referred to as a "penalty box" under conditions such as -12889 (a segment returning 0 bytes after 1.0 × target_duration) and -12888 (a playlist remaining unchanged beyond 1.5 × target_duration). Are there recommended practices to reduce this excessive switching? Specifically: Is there an API to control this penalty box behavior? Would preparing an LL-HLS stream with 1-second parts settle this down? Alternatively, would 4-second segments with a slightly smaller configuredTimeOffsetFromLive help stabilize this?