[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 18/04/13 23:18, Julian Hall wrote: > > To be honest, I don't think it makes a blind bit of difference what > technology movies are streamed with. I would have thought a movie of a > particular length will, assuming it's streamed with the same quality > settings, use up the same - or similar - amount of bandwidth whether > it's sent via HTML5 or another method, so I don't think the data content > is the issue. The size of a movie will depend on the format used to compress it. The leading format in terms of industry usage is H.264. You may remember the controversy with Google VP8 in webm and HTML5 video, but H.264 results in better compression. Video codecs also have other properties of interest, which mostly affect the video producers, but some like how readily it can be played backwards, or show intermediate frames when fast forwarded, have some interest for end users (possibly not much in the common use cases). Typically the big providers will scale movie quality down to the available bandwidth, the better the codec compression (and the flexibility it allows to do this) the better the end results. So the bandwidth consumed is likely to be similar across a lot of formats, but those with the better codec will get better quality playback and a better experience. That said patent issues aside, H.264 is available pretty much everywhere now. Firefox will support H.264 on Windows shortly (already in test), and other platforms eventually (mobile is there already). In each case Firefox uses native codec, or hardware support on the platform to avoid licensing issues over (software) patents. With the death of Flash on mobile, the mobile providers were forced down this route, and IOS and Android both support H.264 (Firefox Mobile supports H.264, again I presume using native support it finds on the devices). That said the delivery via HTML5 or Flash doesn't restrain the choice of format much, and H.264 is available in both on most platforms. Although the dash to H.264 risks side-lining free software users in jurisdictions that enforce software patents (mostly the USA). Meanwhile technology doesn't stand still. Google already have VP9 in their latest browsers, the most significant change is the attempt to break the compression lead that H.264 had, but also offering support for additional audio formats. H.265 has quietly arrived, but I don't know what advantages it is suppose to offer. That said the original reference to "stuff" (language Tom) blocking up the wires, is I suspect a reference to the complexity of DRM, rather than data. Realistically you can't deploy even vaguely effective DRM where the codec and other layers are deployed in free software. Since people can go in and save the data at that layer. So anything stuffed into free software browsers is going to be utterly pointless (as DRM is generally). It is all power play, and big money trying to control the player market, which inevitably is good for their short term profits, and bad for end users and progress. The big hope for free software users is probably still VP9, and it is an area where technical expertise can make a difference. The software involved in encoding and decoding these video formats is pretty complex, and the software available for H.264 for example lags the standards (not perhaps as much as browsers and the W3C, but fair to say there are features in H.264 which are not easily utilized with current software). Someone skilled in programming and wanting a free software win, could be making as full an implementation of WebM, and VP9 work everywhere, particular easing the ease of install, and supporting playback on multiple devices and in IE for Windows etc. It is a fairly daunting undertaking, but for the moment you still have Google's support. -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq