apologies, that was *supposed* to be off-list but I failed at mail :-/ John
On 23 June 2016 at 21:37, john slee <indig...@oldcorollas.org> wrote: > Hi, > > Replying off-list because not an OpenBSD issue. > > On 22 June 2016 at 01:49, jsg <f...@speednet.com> wrote: > >> For those of you running http in support of your business, are any of >> you providing >> videos for your customers ? >> If so what packages and set-up are you using? >> Any advice guidance appreciated. >> > > Some background: I look after video transcoding and delivery for a > news-media organisation. We serve around 200-250TB of video content a > month, mostly short videos up to a couple of minutes long, sometimes much > longer. New videos every day, sometimes hundreds of them. > > There's a lot to learn here but I'll make a few major points: > > * there's two major types of video delivery (plus Adobe Flash, but we're > in 2016 now!): > - Progressive: one big file per video bit-rate. Nice and simple, and works > on pretty much all non-Apple devices, including Chrome/Firefox > - Adaptive: multiple files per video bit-rate, with manifest files to help > devices find all the files. Used on Apple devices. Otherwise known as HLS, > or HTTP Live Streaming. Check browser support carefully. When I last tried > it, this HLS was not supported in Chrome/Firefox. > > * some web platforms also only support one or the other. Eg. Facebook, as > far as I'm aware, only supports Progressive delivery. > > * a webserver that supports Range headers/HTTP 206 responses is important > if you are serving Progressive videos that aren't very short; this can help > the user seek within your video > > * don't forget to set Cache-Control headers > > * if you expect to serve a lot of content, consider a CDN. We use Akamai, > but they are quite expensive and if you don't need all the fancy features, > not worth the money. Maybe Fastly, Amazon Cloudfront or even Varnish > Software's "DIY CDN" toolset? > > * it's easy to provide users on desktop and iOS a consistent, pleasant > user experience with video > > * two years ago it was pretty much impossible to provide users on Android > a consistent user experience with video. I don't know if this situation has > improved or not. Probably not :-( > > For transcoding, the standard seems to be ffmpeg. I strongly suspect this > is what underpins most commercial transcoding platforms (eg. Brightcove's > Zencoder [which is what we use...], Amazon ElasticTranscoder, Akamai's > transcoding product, etc) and that what you pay for with the commercial > products is support and "glue" infrastructure. I don't have any references > to back this up, though. I do know that ffmpeg is what we used before we > (for unrelated reasons) switched over to Brightcove's platform, and at > least one other major media organisation here also uses ffmpeg. Probably > most of them do, really. > > Put some serious effort into tracking what your users are viewing. Eg. > with the previous version of our video platform, we noticed that >98% of > Progressive video views were of the maximum bitrate, and ~95% for Adaptive. > So we were able to eliminate the renditions that almost nobody looked at, > and saved a lot of storage. It also tells us that maybe we could look at > offering our users higher bitrates. > > I'd like to echo the other comment on-list: seriously consider YouTube. > It's free, it works everywhere, and doesn't need Flash. The only reason we > don't use it ourselves is that people in our organisation wanted (much) > more control of video advertising than YouTube offer. > > Happy to help with anything else video, just ask :-) > > John
