Add support for duplicated virtual cameras#2262
Add support for duplicated virtual cameras#2262TheTripleV wants to merge 11 commits intoPhotonVision:mainfrom
Conversation
spacey-sooty
left a comment
There was a problem hiding this comment.
Processed view on duplicate cameras seems to be linked to processed view of main camera even if I change pipelines on the duplicate. Views also seem to randomly display camera lost temporarily when I have a lot of duplicates
|
Oh I also got this crash after running for a while (input empty spammed for a while): Trying to startup after that crash gave me this (input empty spammed for a while): |
| <v-col cols="6" md="3" class="pb-0 pb-md-3"> | ||
| <v-btn | ||
| color="secondary" | ||
| style="width: 100%" | ||
| :disabled="isCameraDuplicate(module)" | ||
| :loading="duplicatingCamera" | ||
| :variant="theme.global.name.value === 'LightTheme' ? 'elevated' : 'outlined'" | ||
| @click="duplicateCamera(module.uniqueName)" | ||
| > | ||
| <v-icon size="large">mdi-content-copy</v-icon> | ||
| </v-btn> | ||
| </v-col> |
There was a problem hiding this comment.
Make sure this button only shows up for USB cameras
There was a problem hiding this comment.
Why can't we duplicate a non USB camera? It seems like a nice feature to have
There was a problem hiding this comment.
I can't test that.
This implementation only works with cscore, which non-usb cameras don't go through.
To do this feature everywhere, we would want to rearchitect how camera input is done. Right now, every vision module (camera + pipeline pair) has a thread. It would be changed so every camera has it's own thread and every pipeline has it's own thread. And data duplication would be fully handled inside photon instead of delegated to cscore.
There was a problem hiding this comment.
Yeah I think we can tackle that later. libcamera devices are generally underpowered and can't do OD yet anyways, so i am fine to leave those unsupported.
Question remains -- can we make sure this button is always shown but disabled for non-usb cameras?
There was a problem hiding this comment.
Done. Though I don't have a non-usb camera to try the negative case
There was a problem hiding this comment.
You can actually simplify this whole check to "is this camera a usb camera"?
| /** | ||
| * Called when a source camera is deactivated or deleted. Handles cleanup of dependent duplicates. | ||
| */ | ||
| private synchronized void handleSourceCameraRemoval(String sourceUniqueName) { |
There was a problem hiding this comment.
If the parent camera is deleted, is there any path to recovering its duplicate children? Should we instead delete all children when the parent is deleted?
There was a problem hiding this comment.
The behavior right now is:
- When a parent camera is deleted, all active duplicates disappear from the list. Deactivated duplicates remain.
- When photon starts, all cameras including duplicates appear in the list.
- When a parent camera is activated, all duplicates are activated too.
Slightly glitchy. There's probably a better way to do that logic here.
There was a problem hiding this comment.
Now,
- When a parent is deleted, duplicates are deactivated
- When a parent is activated, all duplicates activate
- When a parent is deactivated, all duplicates are deactivated
…plicate from config





Duplicate cameras make a DuplicateVisionSource with a DuplicateFrameProvider. DuplicateFrameProvider is a USBFrameProvider but it makes a new Cvsink. All camera properties are either noops or delegate to the source camera.
Workflow
Press the copy button on a camera to duplicate it into a virtual camera

Use it like a normal camera. Input settings are disabled because they are really camera settings. Other pipeline specific settings and output settings are allowed to be changed.

Duplicate cameras show up when their associated source camera shows up.
Small unrelated fix: If a camera is renamed, it will be renamed in the cameraConfigs screen too now. Though I think the whole camera renaming ux should be moved to the cameraConfigs page.