The chunk-list file contains the URI for the decryption key and the list of encrypted ‘.ts’ files.
At which point the decryption of the ‘.ts’ files happen, when we play the file in a media element player.
Wowza Streaming Engine is not able to deliver directly the TS media chunks. It is following the Apple HLS stream initiation process and the client will first need to request the playlist manifest, then the chunklist available for that stream and then sequentially request the TS media chunks.
As far as decryption:
a. Player must first call onHTTPCupertinoEncryptionKeyRequest to validate that he can access the key.
b. Then player must call onHTTPCuppertinoEncryyptionKeyData to get the key.
c. Then player can play the video by decrypt it.
You can check your player documentation to confirm it supports this and then you can test out the validation. You can also confirm by using this helpful article:
https://www.wowza.com/docs/How-to-test-AES-encryption-for-Apple-HLS-streams
To be precise, I can’t get hold of why the vlc media player is not able to play the stream , when it has been provided with the chunklist file which contains the details to the decryption end point?
Thank you for clarifying. VLC does not support AES encryption, so that is why we use it as a test for the encryption. If you did it correctly, it should NOT work in the VLC Player. Does that help?
Thank you 
That helps a lot
When I tried to stream the playlist file which is encrypted on my media player, it worked fine.
But when I tried to play the same on the wowza media player, the stream didn’t play and logged the following on the console
“WARN: ProtocolParserCupertinoChunk: parseChunk[http://10.96.132.126:1180/vod/sample.mp4/media_w623881278_3.ts]: Bad start code. Chunk is corrupt: 9f36a5”
When I went through the network calls I found out that all the ‘.ts’ files were downloaded but the call to the decryption key url wasn’t made.
In the earlier comment you’ve mentioned that “Player must first call onHTTPCupertinoEncryptionKeyRequest to validate that he can access the key.” How does it acknowledge that a given player has the authority to access the key.
Any explanation/thoughts on the mentioned concers would be helpful
Seems like I got it. Only the media players/browsers which support the AES encryption will be able to decrypt the ‘.ts’ files and play the stream.
There is one more question that pops up if the above statement is true, how does the mediaplayer/browser know that AES encryption is in place if it is able to support multiple encryption standards like Simple-AES etc…