Re: AVFoundation and the main thread
Re: AVFoundation and the main thread
- Subject: Re: AVFoundation and the main thread
- From: Mailing Lists <email@hidden>
- Date: Tue, 20 Dec 2016 21:06:02 -0500
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 <email@hidden> 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 (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden