The NVIDIA SDK provides several different libraries (NvMedia, CUDA, OpenGL) for generating and processing various types of images and higher dimensional data. The interfaces used by these libraries were written independently to serve different needs, and each has its own means of representing memory and synchronization resources. There is no direct way to exchange data between them. Furthermore, most of the details of how and when resources used by these libraries are allocated is hidden from the application(s).
The NvStreams libraries serve two primary purposes:
They allow resources to be allocated up front, with access restrictions defined by the application(s), and with details of their overall requirements well understood. This is vital for safety-critical systems that must ensure the availability of resources and proper encapsulation of information.
They allow resources to be exchanged between libraries that otherwise do not have knowledge of each other.
This document describes three libraries. NvSciBuf allows applications to allocate and exchange buffers in memory. NvSciSync allows applications to manage synchronization objects that coordinate when sequence of operations begin and end. NvSciStream layers on NvSciBuf and NvSciSync to provide utilities for streaming sequences of data packets between multiple application modules to support a wide variety of use cases. These libraries also make use of NvSciIpc for inter-process/partition/system communication. This library is described in a separate chapter.

Comparison with EGL

Developers familiar with NVIDIA's non-safety SDK may have experience with EGL, which also provides objects (EGLImage, EGLSync, and EGLStream) for sharing resources between libraries. NVIDIA continues to support EGL, but EGL is not suitable for the rigorous requirements of a safety-certified system. Some reasons:
Resources are allocated using one library. That library has no knowledge that resources will be shared with another library. There is therefore no guarantee that resources will be allocated in a way that meets the requirements of the other library. Mapping them may not be possible.
EGL understands only two-dimensional image data. It cannot handle tensors or other non-image sensor data.
The EGL interfaces were not designed with safety in mind and have failure modes not allowed in a safety-certified system.
Porting EGL applications to NvStreams requires more than a simple one-to-one replacement of functions. NvStreams requires the application to be more directly involved than EGL in determining resource requirements, allocating resources, and exchanging resources.

NvStreams Libraries

For more information about NvStreams libraries, see: