Giuseppe makes a great point about whether the video cameras can adjust their bandwidth demand! If there are various camera picture quality and/or picture size settings, it's often helpful to use those that demand the least amount of bandwidth yet still meets your viewing requirements.
You do want to know what the expected bandwidth demand for the video stream will be, and as a rough rule, you'll likely not want to use use a video stream that consumes more than 1/4 to 1/2 the link's bandwidth. This both to allow bandwidth for your data and to also allow some video bandwidth headroom since many video stream's actual bandwidth demand, at any instant, can be much higher than its average demand.
Giuseppe's example is good, but if this is all new to you, here are thoughts to hopefully further clarify his example.
First, Giuseppe's example appears to be assuming a E1 least line with a 768 Kbps video stream. Whether you have an E1 or T1, fractional variant of either, or even other WAN technology, the intent is really the same. Namely to insure your video steam obtains the bandwidth it requires. I.e. the principle is what's important, not the name of the policy with "-2mbp" or "bandwidth 768".
Second, Giuseppe's example assumes the video stream is running across RTP. What's important is that the video stream is correctly identified. Giuseppe's example of using RTP might work just fine, but there are often other methods to match the video traffic. Another method might be to match source and/or destination IP addresses.
There is one possible problem with Giuseppe's example, and that is, using FQ within class-default while placing video into its own non-LLQ class.
Giuseppe's example is 100% correct, from a text book perspective, but my reading of other Cisco documention has led me to believe class-default FQ, on many Cisco platforms, can keep the other defined classes from obtaining the bandwidth specified for them. If this is indeed a problem, Giuseppe's example could be amended one of two ways:
policy-map scheduler-2mbps
class-map video
bandwidth 768 (or bandwidth percent ##)
class-map class-default
no fair-queue
or
policy-map scheduler-2mbps
class-map video
priority 768 (or priority percent ##)
class-map class-default
fair-queue
PS:
BTW:
Depending on your overall traffic, and what bandwith the video stream needs to work well, just FQ, alone, might work for you. This could be done as:
interface serial#
fair-queue (normally the default on E1 and slower - if default, might not show in config - you don't want to see "no fair-queue" in the config)
or
policy-map yourPolicyname
class class-default
fair-queue
interface serial#
service-policy output yourPolicyname
