雖然有五種加密，但是常用的還是CBC，CBC的全稱Cipher Block Chaining ，有點類似於區塊鏈哈，我們先來看下加密方式
上面的圖片從左往右看，初始化IV只有在第壹個塊加密的時候才會用到，而第N個塊的加密IV則是用的N-1(N>1)個加密後的二進制數組。
CBC的解密則也是從左往右看，但是加密時IV在解密時候，只會用於對第壹個塊進行解密，其他塊的解密則是使用上壹塊的加密二進制作為IV進行解密操作。
通過上面的分析就能知道，加密的時候，iv會影響所有數據的加密結果，而解密時，iv只會影響第壹個加密塊的解密結果，其他塊的解密可以直接通過分隔加密數據獲取正確是N-1塊的IV。
這也就印證了為什麽ff能播放我用錯誤的iv解密出來的視頻流數據，因為第壹塊的大小存儲大概是id3 的數據，ff直接丟掉id3的數據，直接解碼後面的視頻數據 ，ff 應該是識別h264編碼頭開始解碼視頻。
那麽從這點可以看出，在使用了key的情況下，IV對整個數據的保密性沒有太大的作用。
再來說說我是怎麽發現這個問題，因為錯誤的IV只會影響第壹個塊的數據，我在第壹次嘗試解密後，直接用ff進行播放，ff能夠解碼並且播放成功，但是相對於其他未加密的HLS流來說，播放我解密後的數據會有3-5s的延時，這讓我很是頭疼，後來我就通過 ffplay -v trace 打印播放解密的日誌，發現視頻數據的id3信息丟失了，那麽出問題出在第壹個塊。然後再次研究m3u8加解密IV的賦值方法，後發來經過多次試驗，正確賦值IV，解密出來的數據能夠及時播放。再後來，就出現了這篇文章的來由。
由此帶來的延展，針對iv在CBC模式下的弱用，AES提供了更多的模式可供選擇，詳細的可以到wiki上了解。
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation