Hi @vinod_kumar1,
Here is how it works: upon hitting “play”, the player will make an API request called playManifest to the Kaltura server [an EC2 instance in your case]. This, by default, will return an m3u8 manifest, for example:
{"entryId":"0_nhvgpnvi","duration":33,"baseUrl":"","flavors":[{"url":"https:\/\/test.kaltura.org:8443\/hls\/p\/102\/sp\/10200\/serveFlavor\/entryId\/0_nhvgpnvi\/v\/12\/flavorId\/0_6l6ee5y1\/name\/a.mp4\/index.m3u8","ext":"mp4","bitrate":851,"width":960,"height":540,"audioLanguage":null,"audioLanguageName":null,"audioLabel":null,"audioCodec":null,"defaultAudio":false,"frameRate":25},{"url":"https:\/\/test.kaltura.org:8443\/hls\/p\/102\/sp\/10200\/serveFlavor\/entryId\/0_nhvgpnvi\/v\/12\/flavorId\/0_rqill4mq\/name\/a.mp4\/index.m3u8","ext":"mp4","bitrate":1337,"width":1024,"height":576,"audioLanguage":null,"audioLanguageName":null,"audioLabel":null,"audioCodec":null,"defaultAudio":false,"frameRate":25},{"url":"https:\/\/test.kaltura.org:8443\/hls\/p\/102\/sp\/10200\/serveFlavor\/entryId\/0_nhvgpnvi\/v\/12\/flavorId\/0_t4t0hjvy\/name\/a.mp4\/index.m3u8","ext":"mp4","bitrate":1668,"width":1280,"height":720,"audioLanguage":null,"audioLanguageName":null,"audioLabel":null,"audioCodec":null,"defaultAudio":false,"frameRate":25}]}
As you can see, the manifest specifies the different flavours [metadata and the URI for each flavour].
When working against a CDN endpoint, the URI will lead to that [an S3 bucket in your case].
So, while the API request to fetch the HLS manifest will be made against your Kaltura EC2 instance, the content will be served from a CDN edge.
Two important notes:
- When using the Kaltura platform for production purposes [as opposed to testing], you should never have a single Kaltura instance but rather, set up a clustered ENV
- HLS is the default ABR [Adaptive BitRate] protocol we use but we support others, includeing HDS and DASH
I’m not sure I understand the question… the Kaltura player code is embedded on the HTML page served to the user. It mostly contains JS code though there’s a bit of PHP in the backend and of course, HTML and CSS as well. As mentioned in the paragraph above, the player makes a playmanifest API request and that returns the URIs for the relevant media resources hosted on the CDN edges. Thus, the actual media content will be served from the nearest CDN edge.
S3 does not work over FTP. The S3 API client is used. For a short introduction to S3’s RESTful API, see:
https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAPI.html
You may also find this doc beneficial:
Yes, the Nginx VOD module, as its name implies, also requires Nginx. We provide our own Nginx package called kaltura-nginx that already includes all the needed modules, configuration templates and postinst scripts.
It certainly would but it’s always best to set SELinux to permissive mode instead. When operating in permissive mode, you still get the auditing capabilities, which can be useful, without the enforcement of policy [which can and in Kaltura’s case WILL hinder critical operations]
If you absolutely do not require email notifications of any kind then you don’t have to deploy an MTA. However, that would mean you’d have to manually set the passwd for all your users, either via the admin web I/Fs or using the API.
(vi) If I manage to complete the installation, then what are the end points/url that are exposed? How do I start getting access to the AMC and start uploading videos?
The hostname used for the Kaltura endpoint [service URL] must be resolvable from both inside the server and from any machine you intend to perform playback from or access the management web I/Fs. of course, whatever port you choose to set up the Kaltura Apache vhost on must be accessible, as well as the port you choose to use for Nginx.