Slashdot Mirror
ITU Approves H.264 Video Standard Successor H.265
An anonymous reader writes "The H.265 codec standard, the successor of H.264, has been approved, promising support for 8k UHD and lower bandwidth, but the patent issues plaguing H.264 remain." Here's the announcement from the ITU. From the article: "Patents remain an important issue as it was with H.264, Google proposing WebM, a new codec standard based on VP8, back in 2010, one that would be royalties free. They also included it in Chrome, with the intent to replace H.264, but this attempt never materialized. Mozilla and Opera also included WebM in their browsers with the same purpose, but they never discarded H.264 because most of the video out there is coded with it.
MPEG LA, the owner of a patent pool covering H.264, promised that H.264 internet videos delivered for free will be forever royalty free, but who knows what will happen with H.265? Will they request royalties for free content or not? It remains to be seen. In the meantime, H.264 remains the only codec with wide adoption, and H.265 will probably follow on its steps."
Several companies made proposals for what would eventually become H.265.
Who won?
Mozilla and Opera also included WebM in their browsers with the same purpose, but they never discarded H.264 because most of the video out there is coded with it.
What? Firefox didn't have H.264 support until late 2012.
Being a videophile, first I encoded everything to divx, then I transcoded to h.264. Now I suppose I'll turn them all into h.265 - it'll be the best quality yet.
Does this format have and built in DRM (pronounced 'Dhurum") or other nasties?
I want to be excited about this but people keep reminding me that software patents suck.
Once a standard becomes good enough, people will hang on to it for a long long time. Why bother re-encoding a complete music library from mp3 even if vorbis/aac is clearly the superior codec? Apple has enough difficulties pushing aac through, and not many hardware producers are including vorbis support. I guess the same could be said for windows xp and desktop hardware.
Apart from the awful English, WebM has been quite successful, too: a lot of software packages use WebM because they don't need to license H.264, and not just open source software.
Video standards aren't replaced overnight, and in fact, in a lot of places can't be replaced at all. The best way of dealing with these kinds of compatibility issues is to offer an alternative when people need to upgrade and change hardware/software anyway. So, let's hope that WebM can compete with H.265, because then we have a real chance of largely getting rid of proprietary video standards.
The answer is some variant of "follow the money", I'm sure, but why doesn't the standards body in question require that the standard be truly open?
Hail Eris, full of mischief...
E pluribus sanguinem
Given how widespread H.264 hardware implementations are and the fact that blu-ray does not have H.265 I'd expect to see adoption first in the video conferencing world (SIP, H.323....CISCO/Tandberg, Polycom, etc)
For real time encoding H.265 can provide 30% reduction of bandwidth at the same bitrate. Transcoded content like what you might do at home will get some benefit but not as much as the real time stuff (streaming will benefit a lot too)
This adds a sunk cost to the barriers to entry into the device market, in favour of the established market dominators (which is what patents are all about), and to the detriment of free market, consumers and technological progress.
The point is that there is not much choice if it is part of an interoperability standard. You simply cannot view a H.264 video on the web with a browser that only supports WebM, just as you'll have no luck to watch NTSC broadcasts with a PAL-only TV. Of course you are free to try to sell that PAL-only TV in the US, but you won't succeed, not because it is bad (the same TV may sell like crazy in Europe), but because it doesn't work with US broadcasts.
You only have a choice if there are two options that both work.
The Tao of math: The numbers you can count are not the real numbers.
Actually, H.666 will be quite cheap. All payment they demand will be your soul.
The Tao of math: The numbers you can count are not the real numbers.
DRM is implemented at the container level, not the bitstream level.
BD+ in Blu-ray Disc muddies this a bit, as it allows transforming the decompressed image based on whether or not other authenticity checks pass.
Good thing software patents don't exist in most of the civilized world then.
Does "most of the civilized world" offer asylum to refugees from regimes with software patents?
The 'H' video encoding standards have NOTHING to do with free-to-use codecs. They are a COMMERCIAL industrial standard, designed to be reasonable and safe to license, because of the patent pool.
Complaining that H265 will include some royalty mechanisms is like complaining that the sky is blue! Even the document that will detail the final H265 standard will NOT be free, just as today you have to pay to get a copy of the H264 standard.
The open-source movement is not the same as demanding "death to capitalism" or the end of profit, as some very stupid people here seem to think. The 'H' standards have nothing to do with open-source. However, because the 'H' standards are not industrial secrets, open-source developers can and will develop open-source encoders and decoders.
Talk of WebM is pure garbage, since the key developers of x264 looked at the source Google released, and discovered that VP8 had illegally ripped off the H264 standard (badly), taking advantage of the fact that VP8 was originally closed-source. In other words, Google was conned (actually, this isn't true- Google knew full well that VP8 infringed hundreds of patents, but simply wanted to transfer millions to the owners of the company).
If people want to be activists over the royalty situation, it should be with this goal. Encoders, and encoded video (including streamed) should be royalty free. Only the decoders (hardware or software) should pay a royalty. This way, once you own your tablet, laptop, phone, or Windows, you have already paid for the licence to decode H265, allowing all apps to use this format freely.
The advantage of H265 (and H264) to end users is clear. Tiny, extremely energy efficient, hardware circuits can handle the video decoding, providing first quality video services on devices of all kinds. The standards allow software teams (like those behind x264) to produce insanely efficient, ultra-high-quality encoding solutions, and also allow work to progress on very fast (although low quality or very high bandwidth) hardware encoders.
H265 promises (if the encoding efficiency shown by x264 is possible for H265) 4K films on existing Bluray technology- which is essential since the collapsing market for disks means that it is most unlikely a new disk standard will ever replace Bluray.
To conclude. Standards are good, and some standards will involve royalties.
FYI, h.264 is a video compression format, and x264 is an encoder that produces h.264 output.
Saying "true sceners don't use h264 they use x264" is akin to saying "I don't drink coffee, I drink Folgers."
Yeah, those issues have certainly prevented h.264 from taking off. Luckily WebM adoption has roared out of the gate... *cough*
#DeleteChrome
Barely a word about the actual nature of the codec in the summary, but lots and lots and lots about patents.
Go jack of in a flower pot anonymous wanker. HD-DVD would have surely been an annoying piece of crap as well, with Microsoft driving it you can count on it. The only difference is, we *know* Blu-Ray is a piece of crap which we would not have known, had it lost the fight and remained in obscurity.
When all you have is a hammer, every problem starts to look like a thumb.
FAT/FAT32 isn't a poor technology, it's a simple technology. It's not very complicated, but the implementation has evolved over nearly 40 years.
Secondly, you don't have to pay royalties to Microsoft for using FAT/FAT32 itself. You have to pay Microsoft if you use the same exact algorithm for storing larger than 8.3 filenames on FAT. You are free to use a different algorithm, and not pay any royalties, or stick to 8.3 filenames as the original FAT/FAT32 did.
If it's all about Apple, then how do you explain Google quietly backing down from their earlier promises to ditch H.264 support in Chrome?
FAT/FAT32 isn't a poor technology, it's a simple technology.
FAT was a poor technology when it was introduced in the 80s: UNIX file systems already had many of the features we enjoy today in the 70s, see V6's file system in 1975, and 8.3 names were already a restrictive choice back then.
It also did not contain significant innovation, as it was basically an implementation of the CP/M file system.
So nobody would use it, unless for compatibility reasons, which is the point of my comment. It certainly never was "innovative technology that one would pay to use". Not in the 80s, and it would be risible if somebody said that it is now. And Microsoft are asking for money now.
It's not very complicated, but the implementation has evolved over nearly 40 years.
It's only been hacked to support larger disks and longer file names, and still it does that poorly (high internal fragmentation, small maximum file size, no support for extended attributes, poor performance on optical storage and flash, and let's not talk about missing features).
Secondly, you don't have to pay royalties to Microsoft for using FAT/FAT32 itself. You have to pay Microsoft if you use the same exact algorithm for storing larger than 8.3 filenames on FAT. You are free to use a different algorithm, and not pay any royalties, or stick to 8.3 filenames as the original FAT/FAT32 did.
The algorithm is part of the standard, You must implement it as it is. And even if you could omit that part of the standard while still claiming that you're implementing it, you would have to tell your customers that they need to only write 8.3 ASCII filenames, and that they won't be able to see files written by others if their names exceed 8 characters OR contain, say, an accented letter. Are you in all honesty convinced that a company could do this and be competitive in 2012?
As an additional information, know that Windows XP is known to blue screen when it encounters files with short filenames not conforming to the standard: Linux developers found that out when they were trying to implement an alternate 8.3 conversion scheme for the vfat Linux module.
As soon as 1 or 2 mainstream players support it ... my bet would be mid-to-late 2013
It's only been hacked to support larger disks and longer file names, and still it does that poorly (high internal fragmentation, small maximum file size, no support for extended attributes, poor performance on optical storage and flash, and let's not talk about missing features).
Hacked -- Improved. Those words are pretty much interchangeable depending on your own view and biases. Also, systems using FAT can use extended attributes if they wish. OS/2 does just fine with extended attributes on FAT, and so does cygwin. Just because FAT doesn't explicitly say this is where you stick them doesn't mean you can't write a file system driver on top of it that puts them wherever you want. Yes, FAT has poor performance on optical storage, but why would you use FAT on it in the first place? There doesn't need to be one file system that works great in every case. I'm not sure why you think FAT has poor performance on flash. It's performance is pretty good on flash hardware made today, especially if you do any kind of caching, in the case of flash, a small write cache even for sub-seconds will virtually eliminate any performance issue flash has. Not really rocket science.
The algorithm is part of the standard, You must implement it as it is.
Bull. The algorithm isn't part of the FAT/FAT32 standard, it's part of what is known as the VFAT standard, which you don't have to implement.
And even if you could omit that part of the standard while still claiming that you're implementing it, you would have to tell your customers that they need to only write 8.3 ASCII filenames, and that they won't be able to see files written by others if their names exceed 8 characters OR contain, say, an accented letter. Are you in all honesty convinced that a company could do this and be competitive in 2012?
No, they don't have to only write 8.3 ASCII file names, they can implement any alternative they choose. Some vendors have, like IBM with OS/2. You can read and write them all day, but yes, if you want to maintain full interoperability between Windows and whatever, then you must either do it the way Microsoft implemented it, or install a Virtual File System driver in windows that understands your new layout.
Hacked -- Improved. Those words are pretty much interchangeable depending on your own view and biases.
No, they aren't in this case. Adding long filenames to FAT, for instance, broke compatibility with previous implementations of the FAT file system, precisely because they were implemented with a hack: invalid directory entries that happened to be ignored by earlier DOS versions, but would confuse other software which was perfectly working until then. Remember the "LOCK" command that Microsoft added in Windows 95 to prevent those utilities from ruining the file system?
Also, I did explain what minor and insufficient improvements to FAT were made, as well as what major deficiencies remained unfixed, so there's no "bias" involved here.
Also, systems using FAT can use extended attributes if they wish. OS/2 does just fine with extended attributes on FAT, and so does cygwin. Just because FAT doesn't explicitly say this is where you stick them doesn't mean you can't write a file system driver on top of it that puts them wherever you want.
Then they're not using FAT, which does not support extended attributes, instead they're using a personal extended file system derived from FAT, which itself is not FAT, is not interoperable with FAT, and will be unreadable and damaged by other software designed for the standard FAT file system. This won't happen with a file system supporting extended attributes, such as NTFS or UDF.
Yes, FAT has poor performance on optical storage, but why would you use FAT on it in the first place? There doesn't need to be one file system that works great in every case.
That's exactly the point, nobody would ever use FAT if it wasn't because of interoperability requirements. It's inefficient on traditional media, and it can be extremely inefficient on non-traditional media, it never works great. Therefore nobody would ever dream to license it for its technology.
Bull. The algorithm isn't part of the FAT/FAT32 standard, it's part of what is known as the VFAT standard, which you don't have to implement.
But there is no such thing as a "vfat standard". "vfat" is the name that Linux informally attached to its file system driver supporting long file names, and that name stuck. The reason is that the native Windows file system driver, with which the Linux driver aimed to interoperate, was called "VFATD", and that was because Windows "386 enhanced mode" drivers used to have a name in the form V-name-D.
Both Microsoft's official specification of the FAT file system, which is referenced by the UEFI standard, and the SD card standard, contain the short name creation algorithm. Beware: that documentation is subject to a restrictive license by Microsoft, and you have to accept it in order to look at the specification.
No, they don't have to only write 8.3 ASCII file names, they can implement any alternative they choose.
And then they're implementing something different than FAT, which is not interoperable, violates the standard, potentially makes Windows XP bluescreen etc. etc.
or install a Virtual File System driver in windows that understands your new layout.
So you're proposing that, in order not to pay licensing fees to Microsoft, a manufacturer should write a device driver for each operating system that currently supports FAT, for all of its revisions past, present and future, for all of the hardware architectures it supports, then distribute all of these drivers with its product, and require their installation before the use of the product? This would be unrealistic if it was possible, but then it's not doable even in principle, because many devices one might want to interoperate with do not have a user-extensible operating system. See Windows RT for example.