Why are camsites behind Youtube and Dailymotion in adapting to HTML5?
- because those two sites have the money and staff to dedicate to this move
- because they (specially youtube) have a lot of influence on the HTML5 standard and had their own reasons to do so (in Google's case, it's because Flash is extremely insecure and they believe in getting rid of it to increase Chrome's security).
- because their use case is simpler (just video playback), while cam sites also need to deal with video ingestion (live video is still a minority of Youtube's content.. Plus, they require the use of external encoders for that case).
On top of that, there's the issue that for the majority of the internet there wasn't a really compelling reason to move to HTML5 since it just worked with Flash. Now, the tides are turning - mobile clients are becoming extremely popular and Flash is on the way to being officially killed. Some sites were aware of those two things becoming a reality and started moving early, while others are waking up to this notion only now.
One reason sites have a hard time switching to HTML5 is the need for SSL certs and having the entire site encrypted. This is expensive and you need more verified code which is why it takes them so long. Also using SSL certs locks your server down to a location so it's easier for people that want to censor you to block you.
Incorrect:
- you don't need "verified code" - for example, on my http/mail server, it's around 5 lines of configuration per service required. And even if I were the one writing the code, it requires just a few more lines of code that I could easily copy/paste from stackexchange.
- SSL doesn't lock you to a location, unless the site operator was naive enough to request a certificate with the IP address instead of hostname. Usually certificates are based on the hostname; you can also get a wildcard certificate which applies for all hostnames that match a pattern (for example, Google's certificate is for '*.google.com' instead of just '
www.google.com'). And you can also add multiple hostnames to a certificate (also using google as an example, they have '*.google.com' , '*.google.com.br', '*.youtube.com' and more on the same certificate).
Also, I believe that you don't *need* SSL for html5 video playback: it is a 'nice to have', not a 'must have'. Although there's a strong push from Google and others to move the web to be completely encrypted (thanks, NSA), with the HTTP2 standard requiring encryption always.
The thing you have right is that it's expensive, but even then not much - it requires additional CPU power, but the latest processors have encryption support on their instruction sets which reduces the cost by quite a lot - at work we enabled SSL for all users and it meant an average 10% CPU utilization increase, which is reducing as we move to skylake processors (and soon kabylake) which are even more optimized.
That wiki is quite misleading - the problem with lag is not because of mobile limitations, but how they have implemented mobile support for now. From what I can see without access to the broadcaster, basically they have two serving paths:
- desktop users get the raw video feed from the broadcaster, so the only lag there is the time it takes to send the video from the model's computer to MFC's servers and then to the users.
- mobile users on the other hand get a re-encoded video feed, which is what adds the extra lag. (The part I cant confirm is where this re-encode is done - either in the model's computer or on MFC's server. One way to test would be disabling mobile feed on the broadcaster and comparing CPU and bandwidth utilization).
There are ways to solve this, but it requires a lot of work on MFC's side to ensure that both desktop and mobile get the same video feed - at that point they will have the same amount of lag.
