What is TLV encoding and why do LiDAR data formats use it?

TLV (Type-Length-Value) encoding is a serialization scheme where each data element is tagged with a type identifier, a length field, and the value itself. Because every element is self-describing, a decoder can skip any element it does not recognize without corrupting the rest of the message. This makes TLV a natural fit for LiDAR pipelines, where software versions across a fleet rarely update in lockstep: a newer sensor stream reaching an older decoder simply skips the unfamiliar fields and keeps processing without error. Outsight's SHIFT platform relies on this kind of open, versioning-tolerant data format to maintain compatibility across a multi-vendor LiDAR hardware ecosystem spanning Hesai, RoboSense, Ouster, Velodyne, and Seyond sensors, all feeding the same real-time processing pipeline.

What is OSEF and how does it relate to LiDAR processing output?

OSEF (Open Serialisation Format) is Outsight's open data format for streaming processed 3D scenes. At each LiDAR frame (typically 20 frames per second), the OSEF structure is a tree containing a timestamp and all associated attributes: tracked object arrays, classification metadata, and optional streams such as Ego-Motion. The format is a core output layer of the SHIFT platform, which processes LiDAR point clouds through a sub-50ms end-to-end pipeline before serialising results into OSEF for downstream consumption. Because the format is open and published without licensing restrictions, any downstream application or integration partner can implement a conformant reader without negotiating proprietary access.

Why do proprietary sensor output formats create problems in multi-sensor deployments?

Each LiDAR manufacturer ships its own binary protocol. A deployment using sensors from three vendors requires three separate decoding drivers, and any firmware update from one vendor can silently break the corresponding driver in the processing stack. In practice this slows integration work, multiplies maintenance surface, and makes cross-sensor fusion harder. A single normalized output format from the processing layer removes that complexity by presenting a uniform data stream regardless of which physical sensors are upstream. This is why Outsight built the SHIFT platform to be LiDAR-native with multi-vendor compatibility across hardware from Hesai, RoboSense, Ouster, Velodyne, Seyond, Innoviz, and many more, abstracting vendor-specific protocols behind a common data layer so that mixed-sensor deployments can be maintained and scaled without driver fragmentation.

What is Ego-Motion data in a LiDAR stream, and when should it be disabled?

Ego-Motion data describes the movement of the sensor itself, covering its position, velocity, and orientation change between frames. It is critical for mobile platforms such as autonomous vehicles or robots, where the sensor is constantly moving and its motion must be subtracted to isolate object movement. In fixed-infrastructure deployments (sensors mounted on ceilings, poles, or gantries), the sensor does not move, so streaming Ego-Motion on every frame wastes bandwidth and decoder cycles. An adaptable data format lets operators suppress those fields for infrastructure use cases. Outsight's infrastructure-based Physical AI approach, where LiDAR sensors are fixed in the environment rather than mounted on moving entities, is a practical example of why toggling Ego-Motion off is a meaningful optimization for real-world deployments at scale.

How does backward compatibility in a data format affect large-scale LiDAR rollouts?

In a large installation, dozens to hundreds of edge processing units rarely receive software updates simultaneously. A backward-compatible format ensures that a unit running an older software version can still parse frames produced by a newer one, and vice versa, because unknown fields are skipped rather than causing parse failures. Without backward compatibility, a staged rollout becomes a coordination problem: every node must be updated before any node can use new format features, which is operationally impractical at airport or city scale. This is precisely the challenge Outsight addresses in deployments like Dallas Fort Worth, where a large number of infrastructure-mounted LiDAR sensors must continue operating across incremental software updates without interrupting the real-time data pipeline that feeds the Motional Digital Twin.

Can a single LiDAR data stream carry output from dozens of fused sensors simultaneously?

A format designed for flexibility can encapsulate the combined output of many sensors in one stream without changing the format structure itself. In large-area deployments such as airport terminals or city intersections, tens of LiDAR sensors are fused into a single shared point cloud, and the resulting tracked-entity stream is delivered as one normalized feed. Outsight's SHIFT platform applies exactly this principle: across deployments like Dallas Fort Worth and Paris-Charles de Gaulle, dozens of infrastructure-mounted LiDAR units are fused in real time, yet the receiving application sees one stream of classified, positioned entities regardless of how many physical sensors contributed to that picture.

Insights

Seven Essential Properties of a LiDAR Software Open Data Format.

The Seven attributes of an Open Data Format for LiDAR Software

When choosing a 3D LiDAR processing software it's important to ensure that it uses an open and standard data format, that must meet seven key characteristics.

Raw data from LiDAR can be very useful in gathering key data points.

And thanks to processing software like Outsight’s Shift platform they can then be converted into actionable insights so useful applications can make good use of them, in this example precisely detecting and tracking people:

A key advantage of using a LiDAR Processing Software that is agnostic to the sensing LiDAR hardware is the ability to output a unique data format regardless of the input device (and very frequently a combination of sensors from different manufacturers, as required in many projects).

Overview of outsight processing software-

LiDAR proprietary data formats and protocols made sense when this emerging technology first appeared, as it shortened the time to market of new hardware products delivering raw data.

The first LiDAR prototypes were not intended to be used for production purposes. The burden of decoding each specific format was on the early users.

However, in order for the technology to reach mainstream use in scalable use cases it is imperative for 3D LiDAR data to be accessible through open data formats.

An open data format is one that has a freely available published specification which places no restrictions, monetary or otherwise, upon its use, thus enabling conformant software to read and write the data in that format can be implemented by others.

The key characteristics of an open LiDAR data format

1. Open

The system needs to be open, in a way that allows it to function without proprietary intellectual property.

This will lower the risk of using the system, as open proprietary formats can be used without restrictions and can support movement from one technical platform or environment, without compromising legal agreements.

Intellectual property is also typically publicly available, which provides greater security and accessibility to a bigger range of softwares and technical platforms.

2. Simple

The processing system also has to be simple to use.

Parsing data on the system must be straightforward and efficient, which is easier to say than to do: more complex formats can be more efficient in some specific use cases, the simplicity is then a trade-off between usability, time to market and performance.

3. Robust

When looking for a LiDAR processing software, one of the key characteristics you should look for is its robustness. For example, data elements should be allowed to be placed in any order inside the message body.

This greatly simplifies decoding drivers, limits bugs and facilitates the following characteristic:

4. Backwards-compatible

Your processing Lidar software should fit your needs at every stage of your data processing process.

Over time, you will most likely find that you have new features and data fields that you would like to add to the system, while safely skipping older or unknown elements, so that they can run seamlessly with existing data fields.

Companies like Outsight releases new versions of the software frequently, that can’t always be deployed instantaneously in your whole installed fleet: several versions will likely cohabitate in the same network and system.

5. Efficient

When using a LiDAR point-cloud software, the last thing you want is for it to incur wastage in processing time, thus slowing down your processes and even compromising real-time capabilities.

Therefore, it is key to ensure that overhead processing time is minimised and bandwidth is optimised.

6. Adaptable

Your system should also be able to react to real-time user requests without changing its structure and decoding patterns, so that only relevant data is sent at all times.

In application-agnostic software solutions like Outsight’s not every user will need the output of every available feature.

For example, in an infrastructure project (where the LiDARs are placed in a fixed position) is not useful for the Ego-Motion information to be streamed on each frame.

An adaptable solution must allow to only stream relevant information for the use case at hand, optimising bandwidth and decoding time.

7. Flexible

Your 3D processing software should be usable for any volume of data.

There will be times that you will need to make use of simple and small-sized volume of data, for example when using a single and low-resolution LiDAR.

Other times, you will need to take advantage of mass amounts of 3D information to perform more complex tasks or simply cover large areas, with the retransmitted point-cloud and associated attributes.

This includes applications where dozens of LiDAR sensors are fused together to create a single output stream.

Therefore, your system should be flexible and readily available to scale and handle data of any volume without any change in the data format.

The Shift Perception LiDAR Software

Outsight’s Shift Perception delivers its output using OSEF [Open SErialisation Format].

It uses TLV-encoding, which is a scheme that is used for optional informational elements and contains code that is associated with time, length, and value.

As seen in the diagram below, at each processed LiDAR Frame - typically at 20 fps - the structure of the OSEF data is a tree that contains the timestamp information and all its attributes, for example Ego-Motion and Tracked Objects’ information.

The seven attributes of an open data format for lidar proces

With the Shift Perception software you will be able to make full use of an open and standard data format that is open, simple, robust, backwards-compatible, efficient, adaptable, and flexible.

This ensures that you can take your LiDAR solution into the future, with the confidence that no matter how your needs, data points, and outcomes change over time, the system will be able to support your goals seamlessly.

Learn more

Explaining 3D LiDAR Preprocessors

The software behind this promising 3D technology

Read article →

Let's connect

Send us a Message

Drop your email and we'll get back to you as soon as possible.

Frequently Asked Questions

What is TLV encoding and why do LiDAR data formats use it?
TLV (Type-Length-Value) encoding is a serialization scheme where each data element is tagged with a type identifier, a length field, and the value itself. Because every element is self-describing, a decoder can skip any element it does not recognize without corrupting the rest of the message. This makes TLV a natural fit for LiDAR pipelines, where software versions across a fleet rarely update in lockstep: a newer sensor stream reaching an older decoder simply skips the unfamiliar fields and keeps processing without error. Outsight's SHIFT platform relies on this kind of open, versioning-tolerant data format to maintain compatibility across a multi-vendor LiDAR hardware ecosystem spanning Hesai, RoboSense, Ouster, Velodyne, and Seyond sensors, all feeding the same real-time processing pipeline.
What is OSEF and how does it relate to LiDAR processing output?
OSEF (Open Serialisation Format) is Outsight's open data format for streaming processed 3D scenes. At each LiDAR frame (typically 20 frames per second), the OSEF structure is a tree containing a timestamp and all associated attributes: tracked object arrays, classification metadata, and optional streams such as Ego-Motion. The format is a core output layer of the SHIFT platform, which processes LiDAR point clouds through a sub-50ms end-to-end pipeline before serialising results into OSEF for downstream consumption. Because the format is open and published without licensing restrictions, any downstream application or integration partner can implement a conformant reader without negotiating proprietary access.
Why do proprietary sensor output formats create problems in multi-sensor deployments?
Each LiDAR manufacturer ships its own binary protocol. A deployment using sensors from three vendors requires three separate decoding drivers, and any firmware update from one vendor can silently break the corresponding driver in the processing stack. In practice this slows integration work, multiplies maintenance surface, and makes cross-sensor fusion harder. A single normalized output format from the processing layer removes that complexity by presenting a uniform data stream regardless of which physical sensors are upstream. This is why Outsight built the SHIFT platform to be LiDAR-native with multi-vendor compatibility across hardware from Hesai, RoboSense, Ouster, Velodyne, Seyond, Innoviz, and many more, abstracting vendor-specific protocols behind a common data layer so that mixed-sensor deployments can be maintained and scaled without driver fragmentation.
What is Ego-Motion data in a LiDAR stream, and when should it be disabled?
Ego-Motion data describes the movement of the sensor itself, covering its position, velocity, and orientation change between frames. It is critical for mobile platforms such as autonomous vehicles or robots, where the sensor is constantly moving and its motion must be subtracted to isolate object movement. In fixed-infrastructure deployments (sensors mounted on ceilings, poles, or gantries), the sensor does not move, so streaming Ego-Motion on every frame wastes bandwidth and decoder cycles. An adaptable data format lets operators suppress those fields for infrastructure use cases. Outsight's infrastructure-based Physical AI approach, where LiDAR sensors are fixed in the environment rather than mounted on moving entities, is a practical example of why toggling Ego-Motion off is a meaningful optimization for real-world deployments at scale.
How does backward compatibility in a data format affect large-scale LiDAR rollouts?
In a large installation, dozens to hundreds of edge processing units rarely receive software updates simultaneously. A backward-compatible format ensures that a unit running an older software version can still parse frames produced by a newer one, and vice versa, because unknown fields are skipped rather than causing parse failures. Without backward compatibility, a staged rollout becomes a coordination problem: every node must be updated before any node can use new format features, which is operationally impractical at airport or city scale. This is precisely the challenge Outsight addresses in deployments like Dallas Fort Worth, where a large number of infrastructure-mounted LiDAR sensors must continue operating across incremental software updates without interrupting the real-time data pipeline that feeds the Motional Digital Twin.
Can a single LiDAR data stream carry output from dozens of fused sensors simultaneously?
A format designed for flexibility can encapsulate the combined output of many sensors in one stream without changing the format structure itself. In large-area deployments such as airport terminals or city intersections, tens of LiDAR sensors are fused into a single shared point cloud, and the resulting tracked-entity stream is delivered as one normalized feed. Outsight's SHIFT platform applies exactly this principle: across deployments like Dallas Fort Worth and Paris-Charles de Gaulle, dozens of infrastructure-mounted LiDAR units are fused in real time, yet the receiving application sees one stream of classified, positioned entities regardless of how many physical sensors contributed to that picture.