From my experience in shipping multiple complex AVFoundation apps, you can safely (assuming you know what you are actually doing) • :
Build AVAssets / Build AVMutableCompositions Build AVVideoCompositors / Build AVVideoCompositionLayerInstructions Build AVPlayerItems Build AVPlayerItemOutputs / Build AVAssetReader inputs / outputs Build AVAssetTrackReaders and whats it--dos-its On background queues / threads / operations. You can definitely not Mess with AVPlayer off of main thread• Mess with AV Layer off of main thread Associate AVPlayers with player items off of main thread (breaks rule 1) Associate AVPlayerLayer with AVPlayers off of main thread (breaks rule 1 and 2) Handle notifications by any AVPlayer off of main thread / respond (you can of course have your own logic do whatever you want but messages to/from AVPlayer, Player Item (once created and associated with a player) etc, should be handled on main thread). Handle KVO from any observed objects on any thread. Honestly, its rarely worth it unless you are super familiar with the API and the underlying core-media nuances, memory pooling / re-use strategies, OpenGL / CALayer nuances / etc and have a real need for making your life more complicated. Basically, most non-realtime / playback objects (transcoding, export, sample reading / writing) are safe for use on a single background thread, but not for concurrent access from multiple threads. AVPlayer / AVPlayerLayer AVSampleLayer etc really wants the main thread, and only that thread. • values for "know","what","you", and "doing", may vary. As your doctor if multithreading is right for you > On Dec 20, 2016, at 12:09 PM, Jens Alfke <j...@mooseyard.com> wrote: > > I’ll also argue that if you’re needing to do this kind of thing from a > background thread, your code isn’t factored properly. > > Managing the UI of the app is far too complex a task to try to coordinate > among multiple threads. The current best practices for concurrent programming > suggest that you should try to minimize the amount of (mutable) state shared > between threads, and instead have the threads interact mostly by messaging. > > So in this specific case, if a background thread does something that requires > a player view to be resized, it should send a message (or post a block) to > the main thread and let the main thread do it. (And hopefully the background > thread isn’t concerning itself with pixels, but instead with something like > the length of a track or the number of tracks, which the main thread’s UI > logic can then translate into pixel dimensions.) > > —Jens > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/lists%40vade.info > > This email sent to li...@vade.info _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
