In life, it’s always more complicated to display and process digital video than digital photo:

  • Video content takes up much more space.
  • Manipulating videos (compression, scaling, recoding) requires far more resources than converting photos.
  • Due to its size, video traffic far surpasses that of all other resources and still requires good bandwidth.

Typical video hosting (like YouTube) allows for:

  • Video uploading
  • Videos to be shown in different sizes/formats

However, making video uploads fast and efficient, like photos on Flickr, just doesn’t work. Hosts never save original videos, and to properly display them, it’s necessary to convert (transcode) the video to different formats: for Flash-players, mobile phones, iPhone/Android, etc. This transcoding requires a lot of processing time. This is why all video hosts have a queue, where uploaded videos await processing.

The queue’s processing speed is determined by how many processing resources a host has. Don’t be surprised if you have to wait several hours at peak video periods.

A rough outline of a host’s workflow may look like this:

videohosting

Pictured here is what we, for convenience, call the backend, meaning it’s not seen by the user.

  • Freeze-frames (thumbnails) are absolutely necessary – they’re present in almost every video link.
  • Often, when a video is processed, an intermediate format is used so that it can conveniently be transferred to several transcoding processes.
  • Videos can be saved either on the host’s servers or on a CDN (Content Delivery Network). A lot of hosts use all possible storage options at the same time. Remember, traffic is money, and video-traffic is A LOT of money!

There are a few basic ways to distribute videos to users:

videohosting2

  1. Transfer via HTTP to a Flash-application (player). Usually, every host develops its own player according to its own specifications. Understandably, it’s very convenient and inexpensive to maintain HTTP on a server.
  2. Transfer via HTTP to an HTML5-supported browser (<video> tag). In this case, a link to a file is explicitly transferred to the browser, and the (unapproved) HTML5 standard provides the playback function. Naturally, far from all browsers are happy with the <video> tag.
  3. Transfer via HTTP to mobile and smart phones (iPhone, Android, etc.). In this case, a direct link to the video file is transferred to a mobile/smart phone. The fact that different devices support absolutely different codecs and formats (iPhones, for example, support <video>, but only partially) makes things very difficult.
  4. Transfer via RTMP to Flash-applications. This is the most controllable distribution option. The actual content isn’t completely available when the RTMP (TCP) “streaming” protocol is used. This option requires many more server resources and is much more difficult to develop (compared to HTTP). Besides that, it is extremely difficult to carry out this kind of distribution from a CDN.

The simplest and most minimalistic option is option 1, where one of the free players (JWPlayer FlowPlayer) can be used.

So, to make a video hosting platform, you need:

  • File servers for saving videos
  • A good channel or agreement with a CDN
  • Backend – most likely, this will have to be developed from scratch
  • A Flash-player