User Profile

While setting up our premium video-on-demand workflow in AWS, using AWS MediaConvert and MediaPackager and licence delivery from drmToday we encountered an issue with HLS+FairPlay playback (only) in Safari on macOS. The issue is that sometimes (more than 50% on the same video) the videoplayer initialization fails (with simple event of type=”error” in onerror callback). We are using Shaka player in our web application, so we first assumed that this (random) issue could be due to Shaka. However, we also tested with direct playback via the player and we observed the same issue, with same frequency. Since we have some content for which this problem does not occur and other content when the problem occurs very frequently, we tried to understand what could explain this difference. We noticed that for assets where the problem never occurs the order of the video submanifest was increasing, whereas for assets where the problem occurs frequently the order is decreasing. To isolate the issue we created a standalone page for a 2-minute asset and we are able to demonstrate that on this asset, when the bitrates are in decreasing order the playback with Safari on macOS fails more than 50% of the time. Test page using tag: KO: https://ntg-test-public-scr.s3.eu-west-1.amazonaws.com/aws-video.html OK: https://ntg-test-public-scr.s3.eu-west-1.amazonaws.com/aws-video.html?ok=1 Test page using Shaka: KO: https://ntg-test-public-scr.s3.eu-west-1.amazonaws.com/aws-shaka.html OK: https://ntg-test-public-scr.s3.eu-west-1.amazonaws.com/aws-shaka.html?ok=1 Notes: the issue is only reproducible with Safari on macOS (not with Safari on iOS) same HLS content + FairPlay plays OK 100% on tvOS the issue is only reproducible for HLS content with FairPlay (OK if no DRM)

When playing an HLS/FairPlay VOD content, the playback position sometimes jumps to 0 during the transition between local and external playback (and the other way around). The app does nothing during the transition, apart from responding to ContentKeySession key requests. It is not systematic but occurs quite often. When the issue occurs, the playback sometimes resumes to the position where it was before the transition but usually it does not. Most of the time, when the issue occur, the iOS app periodic time observer gets triggered and the AVPlayerItem currentTime() has the specific value 0.001s. Here is an extract of our iOS app logs with the value of AVPlayerItem.currentTime() when the AVPlayer PeriodicTimeObserver is triggered: 📘 [8:21:54.520] Did update playback time: 4512.001719539 📘 [8:21:55.472] Did update playback time: 4512.958677777778 📗 [8:21:55.497] Player external playback active changed to: true 📘 [8:21:57.674] Did update playback time: 4512.001897709 📘 [8:21:57.779] Did update playback time: 4511.974062125 📘 [8:21:57.800] Did update playback time: 4511.995523418 📘 [8:21:57.805] Did update playback time: 4512.001181626 📘 [8:21:58.806] Did update playback time: 4513.001841876 📘 [8:21:59.794] Did update playback time: 4514.001132625 📘 [8:22:00.795] Did update playback time: 4515.001653707 📘 [8:22:01.562] Did update playback time: 4515.766148708 📗 [8:22:01.679] Player external playback active changed to: false 📘 [8:22:01.683] Did update playback time: 0.001 📘 [8:22:01.700] Did update playback time: 4510.0 📘 [8:22:01.737] Did update playback time: 4510.0 📘 [8:22:01.988] Did update playback time: 4509.956132376 📘 [8:22:01.990] Did update playback time: 4509.958216834 📘 [8:22:03.033] Did update playback time: 4511.0015079 📘 [8:22:04.033] Did update playback time: 4512.001688753 📘 [8:22:05.033] Did update playback time: 4513.001998495 📘 [8:22:06.033] Did update playback time: 4514.001205557 📘 [8:22:06.045] Did update playback time: 4514.0325555555555 📗 [8:22:06.080] Player external playback active changed to: true 📘 [8:22:06.800] Did update playback time: 0.0 📘 [8:22:06.814] Did update playback time: 0.0 📘 [8:22:08.168] Did update playback time: 0.002258708 📘 [8:22:08.218] Did update playback time: -0.075460416 📘 [8:22:08.237] Did update playback time: -0.063310916 📘 [8:22:09.298] Did update playback time: 1.001932292 📘 [8:22:10.295] Did update playback time: 2.003054584 📘 [8:22:11.302] Did update playback time: 3.001831125 📘 [8:22:12.301] Did update playback time: 4.001488001 Local -> AirPlay: no issue AirPlay -> Local: the issue occurs temporarily and the playback approximately returns to its position before the transition Local -> AirPlay: the issue occurs permanently and the playback continues from the beginning of the stream. I've filed a feedback for this issue with both iOS device and AppleTV sysdiagnoses: https://feedbackassistant.apple.com/feedback/11990309

During the video playback with the AVPlayer, our iOS and AppleTV apps set AVPlayerItem externalMetadata. Additionaly, the iOS app also sets the default MPNowPlayingInfoCenter nowPlayingInfo. The apps also register to MPRemoteCommands. What works: The iOS NowPlayingInfo center is properly filled with the metadata, the remote commands work well and on AppleTV, using the AVPlayerViewController, the info tab shows the content metadata. Problem: when AirPlaying the content to an AppleTV, the stream is properly played but no metadata are displayed on the AppleTV. I've tried to set nowPlayingInfo on the avPlayerItem or using an MPNowPlayingSession (new with iOS/tvOS 16) but with no luck. Can someone help me display the playerItem metadata on the AirPlay device?

The Context I'm using the HTML video element to play HLS+Fairplay streams (VOD and live) in Safari. My application is a Netflix-like. You can watch a video, stop, and watch another one. Concretly, the <video> tag is created upon each play and destroyed when the player exits. The Problem Sometimes, after exiting the player, launching a new video causes a MEDIA_ERR_DECODE error without anymore explanation. I can trace in my code that the Fairplay certificate and the CKC have been correctly retrieved and that the media session has been created and updated (with the CKC). In fact, when I log everything, I see the exact same logs as when it works. Except the final MEDIA_ERR_DECODE error. When I get this error, if I immediately retry to play, the same error happens, but if I wait about 5~10 seconds, it successfully plays. It's like some resource is waiting to be garbage-collected. What I tried I tried playing non-DRMed videos and it works perfectly: I could play, stop, play, etc. without any issue. So my guess is something is happening at the EME level. I've browsed the whole Internet (twice) and couldn't come up with a clear explanation. Most of the hints I found couldn't explain my issue (e.g. bad DRM-encryption, but how could it work the first time?) or solve it (e.g. videoElement.src = ""). I'm throwing a bottle into the sea, here... Thanks for your help!

Our iOS and AppleTV apps regularly send requests to various endpoints during their lifetime. Requests are sent using URLSession dataTask. Problem: On AppleTV, when the app enters foreground again, it tries to send a request to one of these servers but the request often immediately fails with the following error: Task <1F891A2A-727D-4AE5-A7D1-85099FFBCE5B>.<297> finished with error [-1005] Error Domain=NSURLErrorDomain Code=-1005 "La connexion réseau a été perdue." UserInfo={_kCFStreamErrorCodeKey=53, NSUnderlyingError=0x282a262b0 {Error Domain=kCFErrorDomainCFNetwork Code=-1005 "(null)" UserInfo={_kCFStreamErrorCodeKey=53, _kCFStreamErrorDomainKey=1}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <1F891A2A-727D-4AE5-A7D1-85099FFBCE5B>.<297>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <1F891A2A-727D-4AE5-A7D1-85099FFBCE5B>.<297>" ), NSLocalizedDescription=La connexion réseau a été perdue., NSErrorFailingURLStringKey=https://entitlementvitis.gemtv.cloud/api/entitlement/get, NSErrorFailingURLKey=https://entitlementvitis.gemtv.cloud/api/entitlement/get, _kCFStreamErrorDomainKey=1}  The error occurs even if the app only remains several seconds in background. It looks like the system closes the socket when the app enters background and tries to reuse one when it enters foreground. The HTTP protocol can either be HTTP/1.1 or HTTP2 (depending on the endpoint the app sends the request to). But for endpoints using HTTP/1.1, adding the header "Connection: close" to the request sent before entering background seems to prevent the issue from occurring. However this is not a fix, especially it does not solve the problem for HTTP2. Finally I've not been able to reproduce the issue while profiling the app with Network Instrument. I've filed a feedback regarding this issue: https://feedbackassistant.apple.com/feedback/11990344 Related issue: This issue seems similar to another one we've always experienced: during the app lifetime (again iOS and tvOS), some requests reach a seemingly random timeout, sometime far less than the URLRequest timeoutInterval we usually set at 30s. It looks like the system sends a request through a socket it thinks is still open, but finds out later on that the socket was actually closed on the other side. When these error occurs, the system may log the following: [connection] nw_read_request_report [C1] Receive failed with error "Socket is not connected" [quic] quic_conn_send_frames_for_key_state_block_invoke [C1.1.1.1:2] [-056706ee9dedb1d86333a78c850bed80e55d70ee] unable to request outbound data [] nw_endpoint_flow_fillout_data_transfer_snapshot copy_info() returned NULL nw_connection_copy_connected_local_endpoint_block_invoke [C13] Connection has no connected path Your help would be much appreciated (Eskimo)

We want to allow the enduser to purchase movies from our VOD app using in-app purchases (IAP). Since our app exposes thousands of movies, we plan to create several generic consumable IAP products, one by price tier (according to the expected selling prices). Each productId can be used to buy different movies. Once a purchase is successful (transaction in purchased state), our app needs to send the transaction id and receipt along with the movie id to our back-office in order to perform checks and eventually mark this specific movie as purchased for this user (our app being multi-platform, the purchased movies have to be available on all platforms, whatever the platform used for the purchase). But since the purchase is solely based on the SKProduct (hence its id), and since there's no way to attach some kind of userInfo to the SKPayment added to the default SKPayementQueue, there's no direct way to match an SKPaymentTransaction to the movie whose purchase triggered its creation, especially when dealing with "Ask to Buy" and highly asynchronous transactions updates. So, as far as I know, I have to maintain some sort of permanent context with the movie id, the product id and the last update date in order to try to get the movie id matching a transaction. But there are lots of things to take care of and a high risk maintaining this parallel context synced with the SKPaymentQueue pending transactions. I am pretty sure other apps have the same IAP strategy so I wonder if I'm missing something obvious. Are there some recommendations from Apple on the way to handle it? Or has anyone been through this road and being able to provide advices? Thanks for your help, Aurélien.

My app only offers consumable in-app purchase products. I can successfully purchase a product once but when I try to purchase it again, a popup "This In-App purchase has already been bought. It will be restored for free." appears and the first transaction is restored: the payment queue delegate is notified that a new transaction (with the same identifier as the successful transaction) is updated to the purchased state. I never get a purchased transaction with a new identifier and hence I consider that the purchase failed. Also, each time the app is put in foreground again or at startup, the payment queue delegate is notified that a transaction has been updated (as if it had never been finished). Even though the app properly finishes the transaction each time. Side notes: I guarantee that all purchased or failed transactions are finished (confirmed by the removedTransactions SKPaymentQueueDelegate method being called each time). I even tried to call finishTransaction from the main thread with no success. Right before the subsequent purchase attempts, the transactions queue is empty. I'm also pretty sure I was able to purchase several times the same product last week, with no change in code (same app version from Testflight). I observe this behaviour when building the app with Xcode or when distributed via Testflight. It has not been published yet so I cannot check how it behaves in the Production environment. Do you have any clue on what's going on? Could it be a side effect of using the Sandbox environment? Thanks for your help, Aurélien.

When using rounding methods (rounded(), rounded(toPlaces:), round(_: CGFloat)) on CGFloats with the simulator, the returned value is not rounded at all or sometimes makes no sense at all. (lldb) po (398.0 / 165.0).rounded()e-321 The expression may even crash when called from an attached debugger (the following expression returns 2.4121212... when no debugger attached): (lldb) po (availableWidth / (cellRatio * (tileType.sectionHeight - 50))).rounded() error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0x7c). The process has been returned to the state before expression evaluation. The same operations are OK on a real device or in a playground on a Mac. It's also OK when converting the CGFloat to a Float and calling roundf() as follows: (lldb) po CGFloat(roundf(Float(availableWidth / (cellRatio * (tileType.sectionHeight - 50)))))0 Finally here are the results when passing various rounding rules to the rounded() method: .toNearestOrAwayFromZero: crash in debugger .toNearestOrEven: 2.412121212121212 (unchanged value) .up: inf .down: 2.412121212121212 (unchanged value) .towardZero: 2.412121212121212 (unchanged value) .awayFromZero: inf Is there something wrong with computing rounded values of CGFloats on a simulator?

For Q&amp;amp;A and logging purposes, I need to know whether the response to an URLSessionDataTask comes from the URLCache or not. I've read here and there that it was just a matter of comparing the cachedResponse before and after receiving the dataTask response. But it does not work as each call to URLCache.shared.cachedResponse(for: urlRequest) returns a new instance of CachedURLResponse (each one having another new instance of HTTPURLResponse). Am I missing something? Is there another way to tell if the response comes from the cache?

Hi, We develop an app that sends multicast requests on the local network in order to look for our proprietary hardware (using sockets) and I understand that it now requires the Multicast Networking entitlement (for which I've applied and received no response from Apple yet). However, I'm concerned about the app currently in production on the App Store, and how it behaves on various versions of iOS. Especially, it seems our app (built with Xcode 11) is still able to send multicast requests even if run on an iOS 14 device. However the app built with Xcode 12 systematically fails to send requests on the local network (through CFSocketSendData) on the same iOS 14 device, the local network access being properly granted by the user. Hence my questions: Is the Multicast Networking entitlement only required for apps built since iOS 14 is available (so with Xcode 12)? If so, how long do we have before an update is required with the proper entitlement? Or have I missed something?! Thanks for your time.

I'm displaying a translucent UIToolbar as a subview of a UIViewController which is a child of a UINavigationController (I don't use the UINavigationController toolbar as I want to subclass it). Everything works fine but one thing: when I push another UIViewController on the UINavigationController stack, the next UIViewController edges are not extended behind the NavigationBar until the animation is over. The same issue occurs when the pop animation of the next UIViewController starts. Side notes: The NavigationBar is translucent (by default) Both UIViewControllers are set to extend edges under top and bottom bars The issue is not reproducible if the UIToolbar is not translucent (of if a tint is set). The same issue occurs if the UINavigationController is inside a UITabBarController: the next UIViewController edges are not extended under the tabBar. It's easily reproducible on iOS 12, iOS 13 and iOS 14 devices/simulators, with no code, just storyboard editing. Here's a link to the StackOverflow post I've created a month ago with no feedback from the community: https://stackoverflow.com/questions/63424459/uiviewcontroller-edges-not-extended-behind-top-bottom-bars-during-a-uinavigation