Shaka Player Embedded
|
Shaka Player Embedded supports network request and response filters similarly to the JavaScript Shaka Player project. Also see their tutorial.
Filters are added to either the shaka::Player
(C++) or ShakaPlayer
(Objective-C/Swift) types. Filters are per-Player and can be different with different Player instances. You can also add multiple filters if desired; filters are called in the order they are registered and are called sequentially. Filters are implemented as objects that implement a required interface. There is a callback for request and response calls. You don't have to implement both; if either are missing, a no-op filter will be used.
Network filters can also be completed asynchronously. This is preferable when lots of work is needed since the filter callbacks block either the JS main thread (in C++) or the app main thread (Objective-C/Swift).
In C++, returning a std::future
value is used to indicate async work. An invalid future (e.g. with the default constructor) means the filter completed synchronously. Returning a valid future means the filter is still processing. Once the future resolves, the filter is done. Apps create a std::future
instance by using std::async
or std::promise
.
For Objective-C/Swift, you MUST call the block
argument when the filter is done. This can be done synchronously within the method, or you can call it later if the filter isn't done yet. Forgetting to call the method will cause the request to hang forever.
It is possible for you to report an error from the filter. Doing this will fail the network request. This may result in retries, or it may result in a fatal error. Apps should not use "normal" exceptions to report errors; instead they should create an instance of either shaka::Error
(C++) or ShakaPlayerError
(Objective-C/Swift).