Hi @Jerome and @Djavan,
I have been playing with the Unified example and I’ve ran into an interesting scenario with BebopVideoView and ARDeviceControllerStreamListener.
Check out this use case / chain of events:
Activity A performs discovery, finds a drone and initiates a connection through a service.
User chooses to pilot drone and launches Activity B (Pilot Activity) from Activity A.
Activity B interacts with service, registers itself as a stream listener and enables the video stream.
Activity B receives configureDecoder event and subsequent onFrameReady events and forwards them on to BebopVideoView.
The user then launches Activity C, let’s call this our Settings Activity from Activity B. onPause Activity B stops the video stream and unregisters itself as a stream listener.
The user does stuff in Activity C and leave the activity (back pressed). onResume fires on Activity B, it re-establishes its service connection, re-registers itself as a stream listener and enables the video stream. configureDecoder does not fire, but onFrameReady does. This is fine because the byte buffers for the decoder / codec are still valid / referenced as Activity B was never actually destroyed.
The user then decides that they want to exit Activity B and leave that activity, thus resuming Activity A destroying Activity B in the process. The user does stuff in Activity A and then decides to re-launch activity B. Activity B is recreated, rebinds to the underlying service that is maintaining the deviceController reference, registers itself as a stream listener and enables video. onFrameReady fires but because the decoder / codec was not initialized fails while attempting to process inside BebopVideoView’s displayFrame method.
Is there a way to re-initialize the decoder / codec inherently? I can move the actual stream listener into the service maintaining the deviceController connection but I don’t want to. I can also stuff csd-0 and csd-1 into a static or similar buffer but I don’t want to do this either.