A videostream should probably not be encrypted with either ECB or CBC.
ECB is insecure for almost anything and it should not / can not be used to turn a block cipher in a secure cipher. This is clearly shown even in the Wikipedia description of the mode: find the penguin.
CBC is secure to keep data confidential. It is, however, susceptible to padding oracle attacks when not used correctly - especially in real time communication. It also doesn't allow e.g. caching of the key stream or parallel encryption, so the performance may be subpar as well. And although it does support seeking, it does require the user to retrieve the ciphertext block before the one that needs decryption.
This is why commonly CTR mode is used instead. Sometimes CTR mode is used in combination with a MAC to offer fast authentication and integrity of the ciphertext. , e.g. GCM mode. GCM mode, however, does undo some of the benefits of CTR mode.
However, probably the most common methods of wrapping a stream is to perform TLS. It does have some overhead, but at least well reviewed implementations exists. It depends if it fits your need.
The amount of tries to get to the key will always be in the neighborhood of $2^{127}$ tries for a (largely) unbroken cipher such as AES. The key is protected by the block cipher itself, rather than the mode of operation.
However, the security of the key only is only part of the security of the cipher. It is perfectly possible for a mode of operation to leak information on the plaintext even if the key is kept perfectly secure. The ECB penguin is a prime example of that. Another is CTR mode with a repeated IV, which turns the cipher into a "many-time pad".