First, understand, ToS markings, alone, guarantee nothing. It's up to the transit device to examine the ToS marking and determine how it might treat traffic with one marking differently from another (which it may, or may not do).
Within the RFC that proposed DSCP markings, I recall (?) there are some recommendations. Such as, BE marked traffic is handled as named, i.e. best effort,, AFx1, AFx2 and AFx3 markings might have a difference in drop precedence such that AFx3 will not be dropped before AFx2 which will not be dropped before AFx1. Lastly, to align with the prior IP Precedence RFC, priority, high to low, will not be contrary to IP Precedence, i.e. CS1, AF1x will not have priority over CS4, AF4x. (NB: a later RFC, suggesting a "scavenger" class, using CS1, violates this.) However, assured forwarding really is a slightly different concept than IP Precedence, in that, one AF group doesn't really have "priority" over another AF group, it's more about insuring a level of service (an assurance) to the AF group. (NB: also AF avoids touching what was IP Precedence 6 and 7 as they were/are have network management implications.)
When it comes to CBWFQ, excluding the priority class(es), classes get "ratios" of bandwidth, to each other, based on their bandwidth allocation. So, for example, in your example of providing AF41 traffic 512 Kbps and AF31 traffic 128 Kbps of bandwidth, they will split available bandwidth 4:1. This assumes both are trying to use more bandwidth then is available.
Keeping in mind ratios is what's really important. Actually "obtaining" the bandwidth allocation, as defined, is only true if all (100%) the bandwidth has been defined in the policy-map, and all the classes are trying to use more than their allocation.
When you define a priority class (or classes) you define a queue that has priority over all other class queues. Since it does have this priority, it can "starve" other classes from obtaining any bandwidth. To avoid that, generally CBWFQ adds an implicit policer to the class. So, for example, if you define a priority class with 20% of the bandwidth, CBWFQ will drop traffic, in that class, when it exceeds 20% (but usually only when there's actual congestion - i.e. if less than 100% of the bandwidth is being used, priority class traffic can generally exceed its implicit bandwidth limit).
More specifically to your question:
"In the case of congestion (caused by others traffics) i got finally just 512kb available on my egress, the video traffic will only pass then ? or what would happen ?"
If you mean your logical interface only has 512 Kbps, CBWFQ should reject your policy defining an allocation of 512 Kbps and 128 Kbps.
If you mean (as you write), other traffic is using all but 512 Kbps, again, your AF41 and AF31 traffic would split bandwidth 4:1. However, CBWFQ always has a class-default. So the question is,, what bandwidth allocation has been set for that? Knowing that, we can determine how bandwidth will be allocated.
Let''s assume, bandwidth for class-default has been allocated 128 Kbps, and your link is only 768 Kbps. In that case, the allocation ratio would be 4:1:1. As such, if all 3 classes wanted more than their allocations, class-default would only obtain 128 Kbps, leaving 640 Kbps, not 512 Kbps. I.e. each of the other classes would obtain their full allocation guarantee.
If you have further questions, feel free to ask. Documentation on this can be a bit confusing, but once you really "understand" it, it's actually pretty simple.
