Does it matter if IV is used as the first block of data before the encryption and then some fixed value is used for the actual IV? Usually the IV for the crypto operations is chosen randomly and is sent together with the encrypted data [at the first block]. For decryption, the IV is first extracted from data and set separately in the crypto components (functions or HW peripherals) and then feed the crypto operation with data.



The other case is to set the IV always to fixed value but the first block of data is chosen randomly. In this case after decryption the first block will be just ignored!



In terms of result, I understand that the encrypted text are different but in terms of security does anybody know if it matters or not?
Actually, that turns out that it's sometimes a useful way of implementing CBC mode (at least, with the understanding that you don't send the value you have labeled 'Initialization Vector', but instead the first cipherblock you generate will be sent to the decryptor as the CBC mode IV, and the rest of the cipherblocks will be sent to the ciphertext.

It is easy to see that if the decryptor uses the standard CBC decryption process with the provided IV and ciphertext, he'll get the plaintext.

So, why is this useful?  Well, one requirement for CBC mode is that the IV be unpredictable (specifically, unpredictable to someone who doesn't know the key; if they know the key, they don't need to predict IVs to verify potential plaintext blocks).  With the standard CBC mode implementation, you are given the responsibility of generating unpredictable values, which is not especially cheap.

However, with your construction, it turns out that we no longer require that the first block (that is, the one you labeled 'Initialization Vector') be unpredictable; it is sufficient that it just be unique - after it passes through the AES function, it'll become unpredictable.  Hence, it is sufficient that it can be a counter, which is a lot cheaper than an unpredictable value.

However, you'll say, you perform another CBC mode block (which involves another AES block operation); doesn't that increase the cost?  Well, sometimes, it doesn't - specifically, if you have some encryption hardware that performs a CBC mode encryption as a primitive, then the cost for encryption one additional block is usually fairly minimal (and certainly a lot cheaper than a side operation to generate an unpredictable value).

So, if you are in this specific scenario, yes, it can be a nice optimization.