如何正确处理AWS，CLoudFront视频流？

Question

Sorry if question us duplicate I can't seem to find answers to my questions . Using s3 and cloudfront to stream videos for web project using Laravel . Objects in bucket are private .

Bucket policy

{
"Version": "2008-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
    {
        "Sid": "1",
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity ENE98C17OQICY"
        },
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::bucket_name/*"
    }
  ]
}

What we want to achieve is to send content partially , chunk-by-chunk from cloudfront but it seems to be just streaming the hall video with one request .

Also I was wandering if it is impossible to prevent video downloading from user side even with cloudfronts partial content delivery?

The main question what time shall I send as expiry date ? Videos have different duration's. A video might be 60 second , the next one 150 seconds . Shall I set it individually per video ? or there is optimal solution ?

As after expiry has expired users can't watch the videos without refresh .

Thanks and sorry if this is duplicate I can not really figure this puzzle .

Answer 1

If you want to stream your video chunk-by-chunk you need to first process your video to convert it to HLS or Dash.

You can use AWS Media Convert or AWS elastic transcoder to do so.

If you want to quickly experiment with both protocole, I recommend you to deploy this cloudformation template : https://aws.amazon.com/answers/media-entertainment/live-streaming/

So every time a video (mp4) will be deployed in the the s3 source bucket media convert will process it, save it to s3 destination bucket and finally update dynamoDB with the correct Cloudfront URL for Dash and HLS playlist.

Answer 2

Answering ' Also I was wandering if it is impossible to prevent video downloading from user side even with cloudfronts partial content delivery? '.

The answer is basically, no, I'm afraid.

If the user can play the video then they can make a copy of the stream, even if you make it difficult via authenticated URL's etc.

The usual approach to fight this is to encrypt the file so that even if they do copy it they can't play it without the encryption key.

The next problem is then passing the key securely from the server to the client - this is one of the main functions that DRM systems bring.

Higher security levels of DRM will ensure the video path is never exposed to the application or even the OS, using a secure media path which essentially places the decrypted video in secure memory and renders it directly form there.

Of course, after all this someone can still point a high quality camera at the screen and, if your video is available in high resolution, get a reasonable copy. This is why forensic (invisible) watermarking for tracing is becoming more prominent.

Ultimately, media security is usually about cost vs benefit - ie having enough hurdles that it is not worth someone's while going to the effort to copy it.