Error on writing with AVAssetExportSession with iOS 17.0 (21A5291h), works fine in IOS 16

Question

Created Jul ’23

Replies 4

Boosts 1

Participants 4

I have these code snippets to take an existing video file, write one additional track to it and then write the result to a new file.

  let movie = AVMovie(url: fromFileUrl)
  let mutableMovie = movie.mutableCopy() as! AVMutableMovie

(removed some code here that adds another track to the mutableMovie)

let exporter = AVAssetExportSession(
      asset: mutableMovie,
      presetName: AVAssetExportPresetPassthrough
)
exporter!.outputFileType = .mov
exporter!.outputURL = newFilePath
exporter!.exportAsynchronously {...

This works great up to IOS 16, but from IOS 17 beta I get the following errors in the console of XCODE 15 beta 5

<<<< AVAsset >>>> +[AVURLAsset _getFigAssetCreationOptionsFromURLAssetInitializationOptions:assetLoggingIdentifier:figAssetCreationFlags:error:]: AVURLAssetHTTPHeaderFieldsKey must be a dictionary

<<<< AVError >>>> AVLocalizedErrorWithUnderlyingOSStatus: Returning error (NSCocoaErrorDomain / 257) status (-12 203)

The export then fails with the following error:

Error Domain=NSCocoaErrorDomain Code=257 \"The file couldn’t be opened because you don’t have permission to view it.\" UserInfo={NSUnderlyingError=0x280d15770 {Error Domain=NSOSStatusErrorDomain Code=-12203

Any ideas on how I can solve this? Or is it just a bug in IOS 17 beta that I have to wait for being fixed?

Tested on iOS 17.0 (21A5291h)

Boost

Answer 1

orchetect OP

Aug ’23

I can reproduce this. Issue only occurs on-device with iOS 17 beta 6. Works fine in a simulator.

I believe it's an internal bug in AVAssetExportSession. I've submitted a radar to Apple (FB12986599) with detailed info and an example Xcode project to reproduce the issue.

0

Answer 2

pedromoliv OP

Sep ’23

I can reproduce this.

0

Answer 3

helgehoi OP

Sep ’23

This is still happening in the released iOS17, also on 17.0.1

Have any of you found a workaround?

0

Answer 4

ltctk OP

Nov ’23

We experienced a bug that produced the same error message. In our case, it seemed like the issue was happening after using the copy method to create an immutable AVComposition from a mutable AVMutableComposition, and then letting the mutable version be deallocated while still using the immutable copy. We found a workaround by keeping hold of a reference to the mutable copy so it wasn't deallocted while using the AVComposition, so it's possible a similar solution will work for other cases of this bug. Good luck!

0