Virtual Channels (VC) in Camera Pipelines – A Complete Deep Dive

Modern automotive and embedded vision systems routinely handle multiple cameras simultaneously: fisheye, front-view, rear-view, surround-view, driver monitoring, long-range perception, etc.
To make this scalable and pin-efficient, camera pipelines rely heavily on a concept called Virtual Channels (VC) in MIPI CSI-2.

This blog explains Virtual Channels from the ground up, clears common misconceptions, and connects the concept to real hardware pipelines involving serializers, deserializers, CSI ports, and SoC camera frameworks.

If you’ve ever wondered:

• “Is VC the same as GMSL Link A/B?”

• “How can two cameras share the same CSI port?”

• “How does software distinguish cameras coming over the same CSI bus?”

This article will make everything click.

---

1. What Is a Virtual Channel (VC)?

A Virtual Channel (VC) is a logical stream identifier embedded inside MIPI CSI-2 packets.

Think of a VC as: A tag attached to each video packet that says: “This data belongs to Camera X.”

In CSI-2, every packet header contains:

• Data type (RAW, YUV, embedded, etc.)

• Frame/line info

• Virtual Channel ID (VC0–VC3)

So when multiple streams share the same physical CSI wires, the receiver can still separate them based on VC.

---

2. What Virtual Channels Are NOT

This is the most important clarity:

So:

Link A ≠ VC0
Link B ≠ VC1

Link A/B are physical inputs. VC0/VC1 are logical labels on CSI packets

---

3. Why Virtual Channels Exist

Without Virtual Channels, every camera would need:

• Its own dedicated CSI port

• Its own dedicated lane group

• More pins on the SoC

• More routing complexity on the board

Virtual Channels solve this by allowing:

Multiple camera streams over one CSI interface

Example:

Single CSI Port (4 lanes)
   ├── VC0 → Camera A
   ├── VC1 → Camera B
   ├── VC2 → Camera C

This is critical for:

• Automotive surround view (6–12 cameras)

• Robotics perception stacks

• Compact embedded designs

---

4. Where Virtual Channels Live in the Pipeline

Let’s place VC in the end-to-end pipeline:

Camera Sensor
      ↓
Serializer
      ↓ (GMSL / FPD-Link)
Deserializer
      ↓  ← VC is assigned here
MIPI CSI-2 Output (VC0, VC1, VC2, VC3)
      ↓
SoC CSI Receiver (CSI-Rx)
      ↓
Independent camera pipelines

• VCs exist only on the CSI-2 side

• They do NOT exist on GMSL links

• They do NOT exist inside the sensor

• They are added/managed by the serializer/deserializer pipeline

---

5. How Virtual Channels Are Used with Deserializers

A deserializer aggregates multiple camera links and outputs one CSI-2 bus.
Each camera stream is tagged with a unique VC.

Example: Two fisheye cameras on one deserializer:

On the SoC side:

CSI Port
  ├── VC0 → Fisheye Cam 1
  └── VC1 → Fisheye Cam 2

From the SoC’s perspective, these look like two independent cameras, even though they share the same physical CSI bus.

---

6. VC Is Local to a CSI Port

Virtual Channels are scoped per CSI interface.

So this is perfectly valid:

• CSI-A:

  • VC0 = Fisheye 1

  • VC1 = Fisheye 2

• CSI-B:

  • VC0 = Long Range 1

  • VC1 = Long Range 2

There is no global VC namespace. VC0 on CSI-AB and VC0 on CSI-CD are completely independent.

So: VC uniqueness is per CSI port, not system-wide.

---

7. VC vs Sensor ID (Software Abstraction)

At the software level (e.g., DriveOS SIPL, V4L2, media graph, etc.), cameras are exposed as sensor IDs or logical devices.

Internally, each sensor ID maps to: CSI Port, Virtual Channel

Conceptually:

So when the user configures: “sensorId = 2” They are indirectly selecting: CSI-CD + VC0
This mapping is exactly what ties hardware routing to software pipelines.

---

8. How CSI Ports Map to Deserializers

One common source of confusion in multi-camera systems is the relationship between CSI ports on the SoC and deserializers in the camera subsystem. While MIPI CSI-2 and Virtual Channels define logical multiplexing, the physical topology is shaped by how many CSI receiver blocks the SoC exposes and how deserializers are wired to them.

How many CSI ports are possible?

The number of CSI ports (often exposed as CSI-AB, CSI-CD, CSI-EF, CSI-GH, etc.) is determined entirely by the SoC hardware. Each CSI port represents an independent CSI receiver block with its own lane group and bandwidth budget. The SoC may provide multiple such ports to support scalable multi-camera designs. In other words: The maximum number of CSI ports is fixed by the SoC, not by the camera subsystem.

---

Is there one CSI port per deserializer?

In most real-world automotive and embedded camera architectures, the answer is yes.

Each deserializer typically outputs a single CSI-2 interface, and this CSI-2 output is routed to one dedicated CSI port on the SoC. This creates a clean and scalable one-to-one mapping:

One deserializer → One CSI port

This design is preferred because it:

• Simplifies bandwidth planning (each deserializer has a dedicated CSI lane budget)

• Improves isolation and debuggability (one faulty deserializer does not impact others)

• Matches the natural “fan-in” behavior of deserializers (many cameras → one CSI output)

---

Does each CSI port represent a different deserializer?

Conceptually, yes. In most system designs: Each CSI port on the SoC represents the aggregated output of one deserializer.

Within that CSI port, multiple camera streams are separated using Virtual Channels (VC0, VC1, VC2, VC3). So a CSI port is the physical connection to a deserializer, while Virtual Channels are the logical mechanism used to distinguish multiple cameras sharing that connection.

For example:

• CSI-AB may carry VC0 and VC1 from two fisheye cameras coming from the same deserializer.

• CSI-CD may carry VC0 from a long-range camera connected to a different deserializer.

---

Important nuance

While the one-deserializer-to-one-CSI-port mapping is the dominant and recommended architecture, it is not a strict protocol requirement. More complex topologies (such as splitting one deserializer output across multiple CSI ports or aggregating multiple deserializers into one CSI port) are theoretically possible but rarely used in production systems due to added complexity in routing, synchronization, and bandwidth management.

---

9. Real-World Mapping Example (Deserializers → Thor DevBlks)

Let’s take a concrete system:

• Deser #0 (2 fisheyes) → CSI-AB

• Deser #1 (2 fisheyes) → CSI-CD

• Deser #2 (1 long-range) → CSI-EF

• Deser #3 (1 long-range) → CSI-GH

Typical VC assignment:

Now software mapping:

This is the exact mental model behind SIPL configs and platform JSON files.

---

10. Can One Camera Use Multiple Virtual Channels?

Yes. This is advanced but real.

A single camera (or serializer) can output:

• Full-resolution stream on VC0

• Low-resolution or statistics stream on VC1

• Embedded metadata on VC2

This is used for:

• Multi-stream sensors

• RGB + IR

• Preview + main stream

• HDR exposure channels

In this case: One physical camera = multiple logical CSI streams

Software then treats these as separate pipelines, even though they originate from the same sensor.

---

11. Debugging Virtual Channel Issues

Most bring-up failures fall into these buckets:

Key debugging checklist:

• Confirm VC assignment in deserializer registers

• Confirm CSI receiver is configured for those VCs

• Confirm software sensorId → (CSI port, VC) mapping

• Confirm total bandwidth fits CSI lane budget

---

12. Mental Model Summary

Here’s the clean way to think about Virtual Channels:

Virtual Channels are logical stream IDs inside CSI-2 packets that allow multiple camera streams to share the same physical CSI interface.

Or in one line:

Physical links bring data to the deserializer; Virtual Channels separate streams on the CSI bus.

---

13. Final Takeaway

If you’re designing or debugging a multi-camera system:

• Links tell you where the data comes from physically

• CSI ports tell you which SoC receiver gets the data

• Virtual Channels tell you which camera a packet belongs to

• sensorId tells software which camera pipeline you’re controlling

Once you understand this separation of concerns, multi-camera systems stop feeling “magical” and start feeling cleanly layered and debuggable.

---