If your equipment supports the dual level PQ/LLQ, then using that (level 1 for voice, level 2 for video) would work best for providing that traffic the SLA it really desires.
For equipment that doesn't support dual level PQ/LLQ and/or for video bandwidth that pushes overall PQ/LLQ bandwidth requirement to, say, greater than 50%, the other approach would be to place video in a "normal" queue, but ideally NOT with minimum bandwidth if you're going by "average" video bandwidth usage. (NB: doing that is often a good way to trash that video's quality.)
For a "normal" queue, you would want to allocate bandwidth that the video needs for its maximum consumption, or ideally, somewhat more.
For video in a "normal" queue, first you want to insure its traffic's packets are not dropped. This might be accomplished by using large buffers for that queue and/or pushing up the queue's bandwidth allocation (the latter insuring higher priority to dequeuing its traffic before other queues - i.e. somewhat like PQ/LLQ behavior). The latter, like PQ/LLQ, also avoids jitter and/or latency issues.
Even when you have the dual PQ/LLQ, placing RT video in a "normal" queue allows better QoS tuning vis-à-vis other traffic. This often becomes more important if your video traffic, in PQ/LLQ, needs/uses a large percentage of your bandwidth, as the more it uses can be adverse to your other traffic. (NB: I recall Cisco recommends not allocating more than 1/3 or your bandwidth to LLQ for this reason.)
