On 12/30/2011 9:29 PM, S. Dale Morrey wrote: > Hi Everyone, > > I've been brought in to consult for a new video streaming site that > expects to launch 3Q 2012. > We had a first meeting today and there were some questions that came > up that frankly I'm not sure the best answer to and I had hoped to > pick the brains of the good folks at PLUG to help me come up with some > answers. > > <snip for length>
I can't speak to pricing, but working with studios for in-flight entertainment, I can speak quite handily to a lot of the other aspects of this. -Formats: an mp4 is a good, well-supported container format. I geek out on mkv personally, but it's a poor business decision when the support for it is nowhere near prolific enough. For audio streams, I'd go with AAC or MP3 audio. Video is good with H.264 with Baseline Profile for your portable devices, High Profile for your more powerful devices. Don't get sold on high bit-rates. At a certain point, it's just way more data to process and doesn't give you the extra quality. Doubling your bitrate for 10% quality improvement is silly (though how you measure quality in percentage is up to you). Have you thought about subtitles? Even if you don't offer them for the whole show, you'll need to consider them for some of the content being streamed. Trust me, it comes up a lot. Having a flexible sub format is important, and truth be told, I don't know what support for built-in filters are in all the OSes you mentioned, so there's a research project for you. -Storage/Transcoding: Don't transcode. Just don't. Encoded it in the different formats for target devices, and then let those devices handle minor differences in resolution or whatnot. Also, start a little lower in resolution than the device supports. The reason I say this is because a) transcoding is still rather CPU intensive, especially with the H.264 standard. Even with dedicated hardware, you're looking at only a few streams per device, whereas if you spent some cycles up front to encode them in different formats, you just need some minor extra storage, and then one server can serve several streams at once without much issue (assuming the storage array is well-designed). As for resolution, it is best if you can match the device exactly, but that's nearly impossible with the market today, and if you let the device upscale from a slightly lower resolution as opposed to a higher resolution than it can display, it tends to look better on the device (at least in all our testing over the years), takes less cpu/bandwidth for the device (also adding to quality), and you can cover a lot more devices with one encode. Where the line is drawn on how close you want to be to that resolution is up to you, really, and the studios you work with. It's a far less technical discussion than you'd think, all said and done. For reference, netflix typically streams a FAR less than blu-ray quality and the studios are fine with it, so don't think you have to go for broke to please anyone, especially customers. -Distribution: I'm unfamiliar with all the options for delivery of all this content, since we build our own delivery setups (it's not over the internet). I do know that Akamai is prolific in this space, but there may be newer players in this space that fit better. Amazon is certainly getting there, but I don't know how the price compares. I do know that it's all about bandwidth and number of connections. Latency is not going to be much of a factor, so if anyone talks to you about that, ignore that bit in their spiel. From discussions we've had about the subject, it seems to be more about having multiple points of presence and being able to distribute load between them. That's as much a function of your application side as it is about the delivery network. Tread lightly. Good luck. Let us know what you end up with! -Tod Hansmann /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
