Video library hosting for the recordings you already have

Begin with the recordings, not the machine

Before you compare anything, write down three things about your collection. How many hours of video will be online a year from now, counting what you add every week? How many hours will people watch in a typical month? And on your busiest day, how many of them press play at the same time? A parish posting each Sunday service, a club keeping every match, a festival putting its talks online the day after: each gives a different answer, and each answer points to a different setup.

You also want to know where your audience lives. If they are spread across continents, delivery from several cities matters more than raw disk. If they are mostly in one region, a single well-connected server can do the job.

How much disk your collection will take

Disk per hour is the bitrate in kbit/s times 3,600, divided by 8. We have taken two rungs from Apple's suggested H.264 bitrates: 2,000 kbit/s, the one Apple says should be the default variant, and 6,000 kbit/s at 1920x1080. The hour counts are our own sums in decimal gigabytes, video only.

Talks, sermons and lectures look fine well below the top rate, so most spoken-word archives sit near the left column; sport and fast motion need the right one. Keep your original edit files somewhere else: you only need to upload the copy your viewers will actually see.

How much data your viewers will pull

Every hour someone watches costs the same gigabytes as the hour costs on disk, so monthly data is simply hours watched times GB per hour. Say your archive is watched for 3,000 hours a month at 2,000 kbit/s: that is 3,000 x 0.9 GB, about 2.7 TB. The number that hurts is the busy moment, not the month. If 800 people open a match replay together at 6,000 kbit/s, they need 4.8 Gbit/s between them for as long as they keep watching.

Most libraries follow the same shape: a handful of recent or popular titles take most of the views, and the long tail of the back catalogue is watched now and then. The hot titles are where delivery matters. On the library, each file plays from the nearest of our five cities, so a replay everyone opens at once is not all pulled across one link from one machine. On a single origin server of your own, every viewer of a hot title comes back to that one port, which is why the busy-moment figure, not the monthly total, decides the port you need.

On our video on demand plans that data counts against a monthly transfer allowance, the same one your live channels draw on, and each plan also has a limit on viewers at once. The video CDN page lays out every plan side by side so you can match your numbers to one.

Preparing your files once

Our library does not re-encode anything, so the file you upload is the file people watch. That means it has to arrive in the right shape: an MP4 (.mp4 or .m4v) up to 100 GB, H.264 video in Baseline, Main or High profile, 8-bit 4:2:0, no larger than 1920x1080 and no faster than 60 frames a second, with AAC-LC sound at 44.1 or 48 kHz in mono or stereo, or no audio at all. To check a file you already have:

ffprobe -v error -show_entries stream=codec_name,profile,pix_fmt,width,height,r_frame_rate,sample_rate,channels -of default=nw=1 sunday-service.mp4

You want to see h264, a profile of Baseline, Main or High, yuv420p, a height of 1080 or less and a frame rate of 60 fps or less for the picture; for the sound, aac with profile LC, a sample rate of 44100 or 48000 and 1 or 2 channels. A phone recording often shows hevc instead. This turns an ordinary SDR recording into a library-ready 720p file (export HDR clips as SDR from the phone or editor first), with a key frame forced every 2 s, as Apple's HLS guidance recommends so viewers can jump around cleanly:

ffmpeg -i match-highlights.mov \
  -vf "scale='min(1280,iw)':'min(720,ih)':force_original_aspect_ratio=decrease:force_divisible_by=2" \
  -fpsmax 60 \
  -c:v libx264 -profile:v high -pix_fmt yuv420p \
  -crf 21 -maxrate 4500k -bufsize 9000k \
  -force_key_frames "expr:gte(t,n_forced*2)" \
  -c:a aac -b:a 128k -ar 48000 -ac 2 \
  -movflags +faststart \
  match-highlights.mp4

The +faststart flag moves the index to the beginning of the file, so a player can start before it has read the end. If you have hundreds of files to convert, a GPU makes the batch far quicker: see FFmpeg GPU transcoding.

What happens after you upload

1. You upload the finished MP4 to your library; it counts against your plan's space.
2. Each file is given a player and an embed code, which you place on whichever pages you like.
3. Each viewer streams it from the closest of our five cities: Amsterdam, Bucharest, Miami, New York or San Francisco.

The same files can also become a TV channel that runs day and night. You build playlists and rotations, add your own ad breaks (on Platinum, ads served through VAST as well), and each plan with a library comes with television apps for Samsung and LG sets carrying your name, beside a public page in our TV guide.

Library, or your own machine?

Choose the library if one well-chosen file per title is enough, your videos are H.264 at up to 1080p, and you would rather spend your time on content than on servers. Choose your own server if you need several bitrates per title so phones on weak signal get a lighter stream, if your masters are 4K or HEVC and should stay that way, or if you want your own rules on who can watch.

Building it yourself means a multi-bitrate HLS package per title. Apple's specification asks for multiple variants, segments of about 6 seconds that each start on a key frame, and a playlist marked as VOD for static files. FFmpeg's HLS muxer handles all of it: hls_time sets the segment length, hls_playlist_type vod marks the playlist, var_stream_map groups each video rung with its audio, and master_pl_name writes the playlist that lists the rungs. Keep in mind that each rung holds a complete copy of the title, so the disk grows with each one.

Run that on one of our dedicated streaming servers: an entire server whose unmetered port is yours alone, from 1 Gbps included up to 100 Gbps, in any of five rooms, with Wowza, Nimble Streamer, Flussonic, Red5, MediaCP, Centova or Cue installed on request, or your own software. As a guide, about 133 viewers at 1080p fit on each 1 Gbps at 6 Mbit/s apiece, keeping 20% of the port free as headroom. You then look after the web server, certificates and updates yourself.

Honest limits on both sides

• The library plays the single version you upload. If many of your viewers are on mobile data, export a lighter file, or build a ladder on your own server.
• The free video plan is live only; the library starts on Starter.
• Your own machine sits in one city. Viewers far away will wait a little longer for the first frame.
• Selling courses behind a login is its own topic: video hosting for online courses covers expiring links and encrypted segments. Planning the live broadcast first? Read how to stream a live event.

Questions people ask

Is VOD hosting the same as live streaming?

No. On-demand video is recorded and stored, and each viewer starts it whenever they like, so you need disk and delivery. Live streaming sends a signal as it happens and needs an encoder and ingest. Our library plans include live streaming too, so one account can hold both.

Can I embed my videos on my own website?

Yes. Every file in the library comes with a player and a snippet of embed code of its own, and you decide which pages they go on. Pro and Platinum make the player white-label.

Why must my files already be H.264?

Because we do not re-encode. Re-encoding would cost quality and could hide problems in a file. A file that meets the format plays on phones, browsers and televisions as it is, so what you check on your own screen is what your viewers get.

What is the biggest file I can upload?

Any single file may be as large as 100 GB. The total depends on your plan: Starter gives you 50 GB in all, Pro 200 GB and Platinum 2 TB.

How do I work out the data my audience will use?

Multiply the hours watched in a month by the gigabytes per hour of your file. A 2,000 kbit/s file is about 0.9 GB an hour, so 1,000 hours watched comes to about 0.9 TB. Then check the busiest moment: viewers at once times the bitrate.