Native bindings to the NV_stream_remote extension.

This extension provides a generic framework for establishing stream connections when the producer and consumer endpoints are not associated with the same EGLStream object. The cross-process streams allowed by the KHR_stream_cross_process_fd extension are one example of such a connection. Other potential examples include streams between objects associated with different EGLDisplays in a single process, streams between processes residing in separate virtual machine partitions on a single system, or streams between entirely separate systems connected via the internet.

The approach used by KHR_stream_cross_process_fd has several drawbacks:

• It creates a new pair of stream creation and query functions which are specific to both the type of stream and the method used for communicating the stream's identity. Extending this methodology would require new pairs of functions for every new type of stream connection.
• It allows creation of the connected stream objects without any indication of which side will be the consumer and which will be the producer. It even allows, although this was probably not intended, a cross-process stream to be established, but have both producer and consumer exist in the same process, with the other process acting as a voyeur that can observe state and perhaps modify attributes, but not operate on frames.
• The use of file descriptors generated by EGL in one process and accessed by EGL in another to establish communication has potential security flaws, and may not be available at all on some real-time operating systems.

Rather than implement new connection types using this model, we propose a more generic approach that does not require a proliferation of new interfaces and avoids any ambiguities in how the stream will be used. These extensions can coexist with KHR_stream_cross_process_fd, but allow for more control of stream communication by the applications.

These extensions provide the framework with which arbitrary stream object pairs can be established, but by themselves are insufficient to create such pairs. In addition, a separate extension must be used to determine the protocol by which the two objects will communicate. See for example the NV_stream_socket extension.

Several optional types of separate stream objects are defined, with successive levels of remoteness. It should be assumed that a more remote type will be less efficient in transfering images, and therefore applications should choose the least remote type available that is compatible with their use cases.

Requires KHR_stream.