This article is a continuation of the video stream on AWS S3 + CloudFront (http://qiita.com/terapyon/items/b77ac981da790662e247).
--Supports streaming for iOS Click here for preliminary survey --Distributed privately (with viewing restrictions) on CloudFront Click here for preliminary survey --Achieving the latest private while supporting HLS for iOS <This time the main purpose
It is described on p17 of Secure content delivery and effect tracking realized by CloudFront.
Signed URLs generate a one-time URL for each URL and unview it for a certain period of time, but you can specify the URL with a wildcard and use it to sign a valid signature for the directory containing the .ts file. It seems that you can get it.
http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-creating-signed-url-custom-policy.html
In case of boto (Python module), it can be created by giving policy_url (str) to create_signed_url method. http://boto.readthedocs.org/en/latest/ref/cloudfront.html
According to the JAWS Days document introduced earlier, the URI of the .ts file in the manifest file with the extension .m3u8 is rewritten as a Signed URL by adding a domain.
This is possible if you do this dynamically at the timing of watching the video.
The manifest file had the following simple format, so it seems good to rewrite the line that does not start with "#". (Achievable with a simple parser)
Manifest file example.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-ALLOW-CACHE:YES
#EXT-X-TARGETDURATION:11
#EXTINF:10.866922,
hls_400_00000.ts
#EXTINF:10.817778,
hls_400_00001.ts
#EXTINF:10.815044,
hls_400_00002.ts
.
.
.
#EXT-X-ENDLIST
I'm worried about where and when to do this ...
As a method under consideration, the application server (assuming Plone this time) acquires the original manifest from S3 (or CloudFront), rewrites it to the Signed URL, and distributes it.
It seems necessary to consider how much this rewrite is added every time the URL is accessed. Especially in the case of PC access, this conversion is unnecessary because it is viewed by RTMP instead of HLS.
If you do it when the manifest file of the application server is accessed, there is no need to convert it carelessly in RTMP, so there may be no problem. (Video.js will select two sources, so I feel like this is okay)
By integrating various technologies, I think we are in a situation where it seems possible to implement the desired functions. In fact, I'm going to experiment with this method of streaming.
TODO
--Try Signed URL Custom Policy (specify allowed content with wildcards) --Experiment whether it is possible to rewrite the manifest file