|
CVBpy 14.0
|
|
|
CVBpy 14.0
|
Handler object for multiple synchronous streams. More...
Inherits object.
Inherited by SingleStreamHandler.
Public Member Functions | |
| None | finish (self) |
| Stop the handler. More... | |
| None | handle_async_stream (self, List[cvb.Stream] stream_list) |
| Asynchronously called for all registered streams. More... | |
| None | handle_async_wait_result (self, List[Tuple[cvb.StreamImage, int]] wait_result_list) |
| Asynchronously called for all acquired images. More... | |
| bool | handle_error (self, Type[Exception] type, Exception value, Any traceback) |
| Asynchronously called for all acquired images. More... | |
| None | run (self) |
| Start the handler. More... | |
| bool | try_finish (self) |
| Stop the handler. More... | |
Properties | |
| is_active = property | |
| bool: Check if the acquisition thread is running. | |
Handler object for multiple synchronous streams.
This handler provides a convenient way to acquire images from multiple synchronous streams within a dedicated native thread. All streams for this handler must be synchronous (exactly the same frame rate). If this is not the case you will loose images. Please be aware, that there is no way for the application to verify, that the steams are synchronized. For multiple devices usually an external electrical synchronization mechanism is provided.
Create a stream handler object.
stream_list : List[cvb.Stream] List with synchronous streams.
| None finish | ( | self | ) |
Stop the handler.
This will stop the acquisition thread and call tear_down() on the calling thread. This blocks until the acquisition thread has finished, so blocking in a customized handle_async_wait_result() method can lead to deadlocks.
If the acquisition handler is destroyed it automatically finishes.
If an error occured during acquisition this method will rethow it.
| None handle_async_stream | ( | self, | |
| List[cvb.Stream] | stream_list | ||
| ) |
Asynchronously called for all registered streams.
The default implementation just waits for the next image on each stream.
This method is called from a dedicated thread!
stream_list : List[cvb.Stream] List with synchronous streams (provided at creation).
Reimplemented in SingleStreamHandler.
| None handle_async_wait_result | ( | self, | |
| List[Tuple[cvb.StreamImage, int]] | wait_result_list | ||
| ) |
Asynchronously called for all acquired images.
The default implementation does nothing.
This method is called from a dedicated thread!
wait_result_list : List[Tuple[cvb.StreamImage, int]] List with synchronous acquired WaitResults (see cvb.WaitStatus).
Reimplemented in SingleStreamHandler.
| bool handle_error | ( | self, | |
| Type[Exception] | type, | ||
| Exception | value, | ||
| Any | traceback | ||
| ) |
Asynchronously called for all acquired images.
This handler is called for all not explicitly handled standard exception in the acquisition thread. After the handler returned the acquisition thread may finish, but remain in the active state. Be aware that this handler is by default called from the native acquisition thread.
After this handler there will be no automatic call to tear_down(). So you have to call finish() explicitly. If you reimplemented this handler you should return True for all erros you do not want to delivier to the controlling thread. Calling finish() will raise the last delivered error. You may not raise another errror but you may call try_finish() to stop the handler.
type : Type[Exception] Type of the exception.
value : Exception The value of the exception.
traceback : Any The traceback if avaibalbe.
bool True if the error could be handled False (default) if the error should be handled later.
| None run | ( | self | ) |
Start the handler.
This will call setup() on the calling thread, before createing a dedicated native acquisition thread. The acquisition thread will repeatedly call handle_async_wait_result().
| bool try_finish | ( | self | ) |
Stop the handler.
This will stop the acquisition thread and call tear_down() on the calling thread. This blocks until the acquisition thread has finished, so blocking in a customized handle_async_wait_result() method can lead to deadlocks.
If the acquisition handler is destroyed it automatically finishes.
bool True if no error occurred in the acquisition thread, otherwise.