[segmentation] Add video clip autorewind Signed-off-by: Djordje Senicic <x0157990@ti.com>
Add option to specify object classes list file - so that user can specify a different object classes list file without re-compiling the application. - MCT-1081
Simplify API for multiple contexts 1. Simplify context API in ExecutionObject. Replace context_id variants to multiple existing APIs with these two APIs: bool AcquireAndRunContext(uint32_t& context_idx, int frame_idx, const IODeviceArgInfo& in, const IODeviceArgInfo& out); bool WaitAndReleaseContext(uint32_t context_idx); 2. The timing methods for host execution in EOPs and EOs: * GetProcessTimeInMilliSeconds() * GetHostProcessTimeInMilliSeconds() are no longer accurate with multiple contexts and pipelining. Replace these methods and replace with a generic timestamp based approach. There is a single API call to enable time stamps in an application: //! Enable time stamp generation for TIDL API events bool EnableTimeStamps(const std::string& file = "timestamp.log", size_t num_frames=32); If this method is called before TIDL API frame processing, the API will generate timestamps for events corresponding to each frame (e.g. EOP::ProcessFrameStartAsync, EOP::ProcessFrameWait, etc.). These timestamps are then written to file when the user's application completes. A separate script is used for post-processing the time stamps and generating data for the user. (MCT-1073, MCT-1074)
Optimize examples with EOP double buffering - Improve overall loop performance for imagenet and segmentation - Update documentation on performance - MCT-1039
Wall cleanup, optimize ssd_multibox - Fix -Wall errors - Optimize pipeline execution for ssd_multibox - MCT-1015
Video input option and document update - mp4/avi/mov as pre-recorded video input - camera as live video input, let user choose video input port # - refactor examples code - bookkeep each EO's device/host time inside EOP since EO could be shared - documentation update on 650MHz EVE - documentation on video inputs and output - MCT-1015
Report memory usage when device allocation fails TIDL API creates 2 device side heaps: 1. Parameter heap 2. Network heap The sizes of these heaps are specified in the Configuration object, via PARAM_HEAP_SIZE and NETWORK_HEAP_SIZE. Existing behavior: If the heaps are not large enough, allocation on the device triggers an assertion failure with no indication of how large the heaps need to be for successfull allocation. To improve the usability of the API, provide feedback to the user on the heap sizes required to satisfy device side allocations when any allocation fails. Also added `-Wall -Werror` when building examples and fixed failures. (MCT-1035)
Renamed compute engine to EVE (MCT-1005)
Added version to tidl_viewer, build cleanup (MCT-984)
Rename to TIDL * Replace references to TINN in the sources and directory structure with TIDL or TIDL API * Moved the TIDL network viewer (tidl_viewer) from utils to viewer (MCT-983)
Compute input/output size based on network - MCT-974
Fixed color array initialization problem - Fixed label/color mappings for ssd - MCT-974
Add ssd_multibox example to tinn (Part 1) - Uses Single Shot Multibox Detector network in the example - Implementation in part 1 runs a full network on a single device - Add a separate object_class_table for labels and colors - MCT-974
Use malloc for user application buffer allocation - MCT-972 (follow-up cleanup)
Add segmentation example to tinn - Also fixed relative path in config files - MCT-972