How to treat VC traffic depends on whether it places its voice and video in different streams, or the same stream, and whether you want to guarantee it VoIP like quality (low latency, low to no drops, low jitter). (If your VC separates the voice from video, you have the option to insure its voice gets treated like VoIP bearer, while you can allow a higher chance of impairment for just the video component.)
You can mix VC and VoIP bearer traffic in LLQ (or PQ), understanding, the VC traffic, if your LLQ bandwidth is constrained, can be adverse to the VoIP traffic. (Using a different LLQ class for VC, though, does allow it to be rate limited separately from VoIP bearer traffic. However, even when there's multiple LLQ classes, there's [on most platforms] only one LLQ.)
As to whether to mark them the same, I recommend not, so that you can easily distinguish between the two types of traffic, if you need to, by just examining the ToS marking.
If you don't place VC in LLQ, you would generally want to provide it a very high bandwidth guarantee to give such traffic almost LLQ dequeuing priority.
Also don't forget when allocating bandwidth for VC, assume you'll need its max possible, not its average.
