TL;DR version: Don’t waste your time. Kaltura server is prone to problems and the player simply doesn’t work reliably on a number of platforms.
Video has become an important part of many websites, and for some YouTube simply does not cut it any more. Not using YouTube for video though can be expensive, in fact it can cost several thousand dollars a month for some sites to host, serve and encode their video for their reader and watchers. Because of the cost of the service, that I will not name, we took a hard look at testing out the Kaltura Community Edition to see if it would meet our needs and potentially save us thousands of dollars in cost per month.
We choose to install Kaltura on a DigitalOcean droplet and using the guide on Github for a single server install using Ubuntu had the server up and running. The first time round it was pretty easy to get the server running without using SSL, and in fact we were able to do a lot on the install including uploading, encoding, serving video etc. All seemed pretty positive, but then we tried to to do a mass upload of a few files and discovered pretty quickly our test droplet simply did not have the power to handle what we were trying to do.
One of the reasons why we choose DigitalOcean to test Kaltura was because it is easy to resize our test machine. A simple resize of our droplet had the Kaltura server up and running again with more ram and processor power to handle a test bulk upload. We were still testing without SSL but were hopeful that adding in SSL would not be to cumbersome. The FAQ here makes it sound like reconfiguring Kaltura is a simple matter of running, in our case the Debian commands,
# dpkg-reconfigure kaltura-base
# dpkg-reconfigure kaltura-front
# dpkg-reconfigure kaltura-batch
and adding the values to change ports and SSL certificates. In theory this should have been simple and easy, in reality it caused multiple headaches and searches on the Kaltura support boards and on the GitHub Issues section.
The problem often seemed to be related to the zzzkaltura.ssl.conf file not properly having the Apache variables replaced. After some searches we tried to edit the template file for zzzkaltura.ssl.conf located at /opt/kaltura/app/configurations/apache/kaltura.ssl.conf.template without the Apache variables but with our inputs and hoped that our problems would be fixed. No such luck. We still were not able to load Kaltura with SSL, in fact we were only able to get the default Apache SSL configuration.
At this point we tried to disable the default Apache SSL site configuration, much like we had to disable the default Apache website to get the non-SSL version of Kaltura to work. No such luck, we were then not able to load anything from the server and only got 404 errors. At that point we decided to re enable the default SSL site and move all of the settings from zzzkaltura.ssl.conf into the default SSL configuration and we restarted Apache. Much to our surprise the Kaltura Community Edition server worked. Once we got this working doing a few searches on the support forum and issues board found no mention of such a problem. I mention it here in the hopes that if you are having problems getting Kaltura running over SSL that it might help you.
Things were looking up once we got the server running with SSL we thought we might get lucky and actually be able to use the community edition for hosting, encoding and serving our video. Encoding seemed to work well, we had some small hiccups with the players but since we wanted to use a pre roll HTML5 player those small hiccups with the flash players did not seem to bother us. Unfortunately the next hiccup was a deal breaker, and if you are still reading because you are trying to still get Kaltura running I would recommend you stop trying to get the server running and save yourself time and energy. The short version is the HTML5 player in Kaltura does not work with Safari and in our tests that included both Mac OS and several versions of iOS.
We tried several things to get video to play using the HTML5 player in Safari from Kaltura, including some of the fixes listed on this post in the support forum but came up empty. At this point we decided that we had spent enough time trying to get Kaltura Community Edition to work properly and moved on to looking for a new provider to host, encode and play our videos.
I prefer to work with open source projects whenever possible but in this case the problems with the player and issues with setup added to the overall frustration with Kaltura. The project seems to be aimed more at driving people to use their commercial service, which by the time we were done testing Kaltura Community Edition, we wanted nothing to do with. What would be nice to see is the ability to use the Kaltura server for managing and encoding videos, since this part of our testing did seem to work well, but have the ability to use other HTML5 players, like Video.js, in place of the Kaltura HTML5 player.
Update
I have had a couple people email me asking what we ended up using. In the end we landed at StreamShark. While the interface at StreamShark needs some work we have been quite happy with their service and have saved quite a bit of money since moving there. Even built a WordPress plugin to manage our videos with their API.
First I want to say that I am a subscriber to 
Epiblogger is still pretty new and in the rush to open the doors we did not take a lot of time to dust the cobwebs off of all the corners around the place. One of the cobwebs that I wanted to get around to sprucing up is the Epiblogger 404 error page. Many WordPress themes come with a 404 Template included in the theme, but often they are nothing special. As you can see the Epiblogger one does not give you much information.
