MPEG claims its new standard H.265 halves video bandwidth with no quality loss
itwire.com
itwire.com
1. 1080p streaming video from Apple, Netflix and others looks pretty good, but it suffers from more compression artifacts when compared to Blu-ray. It simply doesn't look as good. With a more efficient compression technology, streaming video could have similar file sizes to today's H.264 video but look more like Blu-ray.
2. I already own a laptop that does above 1080p video. When Apple release a Retina iMac or Thunderbolt display it will be around 5k. Other manufactures will be there too. 4k or so TVs and projectors are on their way. Streaming technology makes a lot more sense than a new physical format for higher resolution video. In order to realistically deliver 4k video (or 5k video like The Hobbit is being shot in) over IP, we would need better compression than H.264
3. Files sizes could be cut down, allowing people to consume more video without going over their caps. This would also allow mobile devices to store more high quality video content for on the go.
The best case scenario would be that we get a combo of all three. 4k-5k video content is still a bit way for home use, but when it does come. H.265 sounds like the way to go.
In the next few years, this technology could be used to cut down on file sizes some, while also upping the quality of video. This is what we saw with Apple's 1080p video which uses high profile H.264 video, whereas Apple's 720p video is main profile H.264. Yes, the 1080p videos are bigger, but not by much.
EDIT: I found an article on the subject: http://carltonbale.com/1080p-does-matter/
Not that that will stop them from making them, but it'll be interesting to see what happens after 4k/5k when the limit of how much resolution the human eye can perceive has been surpassed.
Ironically, I might be better able to make use of 4k video on a computer since I sit so close. I find video to be a bit soft on the iPad 3 and Retina Macbook Pro because both have to up-convert 1080p video. I expect to have a 4k or so 27-inch monitor in a few years, and would love to be able to watch native video on it.
I would need to both sit much closer and need a bigger TV to make use of 4k video. I still have a 720p plasma because where my couch is, it's almost impossible to tell the difference between 720p and 1080p.
Glad to know I'm not alone ;)
I do care about video quality although I know that I'm in the minority (many people say that picture quality is the most important thing in a TV but very few of them can actually identify it). Given that my very weak prescription makes such a difference (720P and 1080P content is probably the same without my glasses) it wouldn't surprise me if many people really couldn't see it.
http://superuser.com/questions/441395/what-is-the-maximum-re...
http://en.wikipedia.org/wiki/Red_Digital_Cinema_Camera_Compa...
Maybe it will take a future version of Thunderbolt using optical cables to do a Retina Thunderbolt Display. Or maybe Apple will simply make it around 4k.
This allows Apple to give users the same exact workspace as before, just with 4x the pixels.
They could break this with the iMac and Thunderbolt Displays, but 2x is how I expect all Mac laptops to be in a few years.
I do think it would be a little too complicated though, it's probably more likely there will be a faster Thunderbolt port before that happens ;-)
I think that a major change you will see in the future is the size of the screens. In order to take advantage of a 4k stream a monitor needs to occupy a much larger fraction of your vision than 1080p. So 3 metre screens or projections in people's homes will become more common if resolutions are going to meaningfully increase.
So it might use a little bit more power than h264 with hardware acceleration, but probably not all that much.
eta: For historical and comparative purposes, here's DarkShikari's evaluation of an early prototype of an encoder. http://x264dev.multimedia.cx/archives/360
So I'm wondering is there some new sercet sause in h265 which makes it really much better than say x264 or is it just a new standard created around extra features which encoders like x264 already has implemented?
I've no idea what this means [yet] but it sounds too awesome to ignore. H266 here we come?!?
So it is not exactly outside to the official specs at all.
After a full 6 hours, 8 frames had encoded.
Looks like it's not ready to evaluate yet.
Anyways he explains what happened: instead of choosing sane options, that encoder would iterate through every possible encoding and test each of them for PSNR, for a competition. It's not the kind of encoder you would ever use in practice.
At 0.75 hours per frame, that's 97,200 machine hours, or just under three years even if you have a cluster of 100 machines.
This might be GPU encoding's chance to shine. Right now it's generally considered to not be worth the hassle over a fast i7 machine.
And of course the algorithms will be optimized, maybe by orders of magnitude. But that's still a lot of computation power required, no matter how you slice it.
Reference encoder: http://hevc.kw.bbc.co.uk/trac
Samples: ftp://ftp.kw.bbc.co.uk/hevc/hm-8.0-anchors/bitstreams/
Latest draft of the spec: http://phenix.it-sudparis.eu/jct/doc_end_user/current_docume...
However:
- tablets and phones are unlikely to be able to take advantage of H.265 until the requisite GPU support arrives. This may hold up widespread adoption for a year or two.
- for how long will the video arena remain at 1080p? I hear Sky (UK satellite broadcasting arm of the Murdoch empire) is trying to nudge toward 4K broadcasting.
It's a somewhat backwards way of thinking about it. They chose the filesize and then set the dials for the encoding. They could have chosen the 720p to be smaller larger or the same size compared to 1080p.
Of course, there's a class of users who will just always find the largest video file possible, reasoning that it much be higher quality.
The time when this doesn't apply is when you're currently losing a noticeable about of video quality to keep file sizes down. Say that you're a movie streaming service, and you want to stream a fairly new movie. You have it at very high resolution, but if you wanted to stream it at Blu-Ray quality, that would really eat up your bandwidth, so you decrease the file size to something you're comfortable with, and get as much quality as you can within those limits. Better compression, in that case, would mean either better quality at the same file size, or bandwidth savings at the same quality, or some combination of the two.
So: I would expect this to make pirated TV rips smaller, pirated Blu-Ray rips larger or smaller (depending on what the encoding is optimized for), and streaming video either higher quality or smaller, depending on your connection speed and how much bandwidth they're willing to pay for.
I still remember the days when downloading movies was only practical because someone had compressed them down to two 150-megabyte videos. When I got my first 'high quality' 580-megabyte copy of The Matrix, I was thrilled.
Encoding used to be an art form. Now people just use whatever codec they want with default settings to get that 50GB Blu-ray movie down to a couple gigabytes and call it a day.
Regarding the other thing, MPEG is running two tracks for a royalty-free spec based on existing patent-free tech and on grants from H.264 patent holders (respectively) which they say they will decide on sometime this year. An option like that from MPEG might not take off but can't hurt.
Double track on licensing makes some sense for a profile that can be served or provided free but I expect the efficiency benefits would mean that for commercial uses you would pay. That would mean that most hardware will support both so really I think most decodes will support both.
Maybe people will use the non free for mobile.
EDIT: I mean to say, H.264 implementations (particularly x264) are way, way, way out in front of VP8, so even as the H.264 standard is better, the actual facts on the ground are even more so. The only reason to use VP8 (and let me be clear: I think this is a perfectly legitimate reason) is political.
Using a standard means that I can take a video I encoded with an off-the-shelf tool and play it on any device.
And of course you had to get the encoding settings right before encoding the whole thing, since the moment a VCD was public there were several groups all working to get the first decent quality small video file out there.
The intentions of improving technical side of the codec are also there, but it comes along with expanding the time of the patent grip on the whole thing.
It mentions which ones are expired, but it doesn't say how much longer the remaining ones will be valid.
Looks like the last one expires in 2027.
Even for something R&D heavy like video codecs. How much money are we dumping into the NSA right now? Use some of that.
For codecs, the government would not even need to regulate. As long as the offerings are good, the industry would be compelled to adopt them because of the lack of licensing costs and for the long term stability. Continuous R&D would still be necessary.
There's no reason in principle that the same approach, again with NIST as the relevant institurion, could not be used for video codecs.
It would be better than the MPEG-LA because the patent situation could be made much simpler (e.g. automatic patent licenses would be granted to all implementors of the standard).
It's sad and ironic that Google is doing this more effectively than We The People, it least in cases where their interests are aligned with the commons.
Do you want Web "standards and formats" to last as long as NTSC did? Imagine using IE6 for the next 50 years. That's what government involvement will get us.
Which is why the US and EU governments are fighting against Google, Samsung and HTC who are abusing FRAND obligations and undermining the concept of standards.
I guess we can all complain when the iPhone 5 doesn't support it.
It would have had an opportunity to take off when H.264 was in its infancy. But now there is simply no use for it.
Apple just has no inclination to support it. And why would they ? VP8 is significantly worse than H.264 in every important way (quality, compatibility, popularity). Not to mention that Apple is on a very anti-Google path right now.
The cpu requirements must be intense. If they cannot do it with hardware accelerated video drivers for current hardware, it sounds like it will tie up multiple cores?
Maybe they like the idea of making everyone rebuy hardware.
Deblocking works (very roughly) like this: look at the edges of the blocks and see if there's a sharp edge there. Now check and see how strong of an edge there is there in the original input. Depending on these two relative edge strengths, blur the block edge. That is, if there's a strong edge in the output, but not in the input, blur a lot. If the input does have a strong edge, blur less. H.264 also uses some other heuristics to decide how strong the edge filter should be, and happens to do the filtering on the encoder side as well as the decoder side, which allows for better interframe compression.
So while this, in a vague mathematical sense, does provide overlapping information between blocks in a way that can be analogized to overlapping blocks, that information is far cruder than true time-domain aliasing cancellation
But to answer my own previous question, the reason they don't use overlapping blocks appears to be that that the concept is very difficult to reconcile with motion compensation.
Or technically speaking, what you do is you multiply the blocks by a window function before you do the Fourier related transform. If you choose the windowing function carefully, you can even set it up so that all you have to do is add the overlapping areas together.
This is especially easy to understand in one dimension, which is more or less how MP3, Vorbis and AAC do it. Block boundary effects are so noticeable with audio that unless they are corrected very robustly, the quality is unacceptably choppy.
The technique generalizes basically without alteration to two dimensional data, but I've never seen an image or video algorithm that used it. JPEG just ignores the blocking issue entirely, and video algorithms seem to rely exclusively on deblocking filters. As I said, I think this has to do with the fact that TDAC doesn't trivially generalize to motion compensation.
1. Psychovisual models are overly pessimistic about human perception of dark scenes and bit rate is reduced in these scenes too aggressively.
2. Large areas of subtle gradation cause the motion predictor to use big 16x16 blocks. This would be bad on two counts: i) the deblocker tones down to its lowest level on motion compensation boundaries, and ii) the deblocker can affect a maximum radius of 3 pixels from the edge, which would do little more than make the blocks look fuzzy.
3. Greater quantization in dark areas means that faint, transient noise like film grain is smoothed over, but the edge detector still sees it in the source frame, and that causes the deblocker to turn off (or at least weaken) on those blocks. If the noise were there, it would perceptually mask the boundary, but because it has been lost to other compression techniques, the block boundaries stand out. This particular hypothesis suggests that the problem could be reduced without modifying the spec by adding a simple luma-sensitive denoise preprocessing step.
So with this new standard, are they hoping to cut that down to 45%?
(technically 81.8)