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."

Comments

So who won?

[loufoque]

Several companies made proposals for what would eventually become H.265.
Who won?

Re:So who won?

[Goaway]

Nobody "won". Companies weren't making proposals for complete replacements for h.264. They were making proposals for incremental improvements on h.264. h.265 is a collection of those different improvements. Each one is small in itself, but they add up.

Re:So who won?

[Anonymous Coward]

"Several companies made proposals for what would eventually become H.265."

Translation

"Several companies offered patents for what would eventually become the H.265. royalty pie"

Re:So who won?

[Anonymous Coward]

Then whose patents have now become gold mines and/or roadblocks?

Re:So who won?

[beelsebob]

Amazing how that works. Company does a bunch of research work, and then says "hey, you can use the research work we did if you pay us". It's almost like the people there are normal human beings who want to live and eat!

Re:So who won?

[cynyr]

But if the ITU is going to make it a standard, it really should require patent grants for any patents that would cover that standard, and require all entities that are participating to sign agreements that they are agreeing that any patents they currently hold or will hold in the future will not be used against those implementing this standard.

Re:So who won?

[Anonymous Coward]

"Company does a bunch of research work, and then says "hey, you can use the research work we did if you pay us"."

Translation

"Somebody does some research then a company patents it and every little incremental change every few years to keep old patents alive and to stop anyone else trying to enter the market" ...

"It's almost like the people there are normal human beings who want to live and eat!"

Sorry, I couldn't translate that with a straight face. Its even more laughable and insulting than when the RIAA says it.

Re:So who won?

[samkass]

It's funny how different Slashdot sentiment was when it was discussing Google as the plaintiff trying to get an injunction over standards-essential patents...

Re:So who won?

[alen]

Except for rambus that's how it works

DVD, blu ray, 3G/lte and lots of other standards are patent pools
You donate your patents and agree on a small royalty for anyone who wants to use them

Re:So who won?

[i.r.id10t]

What would be better would be requiring a Free implementation of said standard, and if $BIGCO doesn't want to (or can't due to other obligations) make their resulting product Free as well, they can pay a license fee. Just like all the other dual licensed software/source out there....

Re:So who won?

[Anonymous Coward]

Which standards-essential patents?

Also: there are different people posting on here, I suspect. That might answer a lot of your concerns, if you previously thought there was just you and one other hyperactive, schizophrenic, multi personality poster on here.

Re:So who won?

[serviscope_minor]

Yeah, it's funny. Almost like there's more than one commenter.

Re:So who won?

[spire3661]

The problem is the breadth and scope of how far these patents go. Not being able to profit from video i shot using a consumer grade camera is an unconscionable consequence.

Re:So who won?

[Anonymous Coward]

Or maybe it works by letting people use your patented methods until they become a de-facto standard, all the while refusing to say exactly what is patented. Yup, that's how it really works.

Re:So who won?

[Anonymous Coward]

or you make an apple use those patented functions and do not pay anything at all.

Re:So who won?

[Kjella]

Then whose patents have now become gold mines and/or roadblocks?

The H.264 patent pool has 30 licencors and the list of patents is 59 pages long, so the short answer is: Most of the industry. Apart from Google with WebM and previously Microsoft with VC-1, there is surprising unity. My predictions are as follows: HEVC is as dominant in hardware as H.264, there will be an open source encoder like xvid/x264 and those who can't or won't use that will use WebM despite the somewhat larger size because Google will probably fight to back it as a free codec. Anything else will be never go anywhere outside geek circles like Vorbis or Theora.

Re:So who won?

[Anonymous Coward]

Which standards-essential patents?

I believe he's talking about Motorola's lawsuits against Microsoft using H.264 patents. I don't recall if they started before or after Google had effective control over Motorola, but it seems like anything Motorola did in the patent spats is getting attributed to Google now.

That said, I do think the main point that there should be agreement to keep relate patents within a central licensing pool is a good one. It was kinda goofy that Motorola even had a leg to stand on when suing someone who licensed H.264 from the MPEG-LA. What is the point of having a standards body and licensing pool for that standard if someone can just crush licensors through side-channels anyways.

Re:So who won?

[Guspaz]

As it stands, WebM is somewhat less effective than h.264, and as such, it will never be competitive with h.265... No more so than MPEG-4 ASP is competitive with h.264.

WebM completely failed to gain any traction whatsoever against h.264, so why should it do any better against h.265?

Re:So who won?

[jedidiah]

Google is also in a patent nuclear war with Apple and some of those patents should be thrown out entirely. Like any war, you have to do dirty things to survive because you cant count on the other side being acting civilized.

Patents more and more seem to be nothing but a pointless burden. Both classes should be done away with (the bogus ones and the ones that standard depend on).

Re:So who won?

[Divebus]

You're being very kind by saying WebM is "less effective" compared to H.264. I'd put it closer to "why in the hell would I want crummy looking compression unless I use at least twice the data rate?" This from someone who's livelihood partially comes from putting compressed streams on the Internet. WebM isn't good enough and just got lapped again.

Re:So who won?

[Anonymous Coward]

I've got a two year contract for you upgrading my entire IT infrastructure. You'd be working for free. Can you start Monday?

Re:So who won?

[Anonymous Coward]

Pretty much any "tool" to be had was thrown into the H.265 "toolbox". Which "tools" are actually most useful for video compression will be determined as the art of using the tools for compression is developed over the next few years.

Even MPEG-2 encoders are still getting better each year, but they are starting to asymptote.

Re:So who won?

[Tough Love]

Anything else will be never go anywhere outside geek circles like Vorbis or Theora.

Please watch those overly broad claims. Vorbis is now well established in a number of niches, notably video game sound content.

Re:So who won?

[Anonymous Coward]

ITU like most standards development organizations has a RAND policy (IP must be declared by participants during the standardization process, and must be made available on a reasonable, non-discriminary basis to those implementing the standards).

The problem is with folks not part of the process who hold IP that may be infringed by people using the standard.

I believe that any important ANSI-approved standard should require a "put up or shut up" period of one year - after public notice, any non-participants must state if they have IP that is essential to the standard within that year period.

You don't have to do this for every standard, but something like H.264 and H.265 is a very widely-used and important standard that you'd prefer not to have submarine IP in.

Re:So who won?

[UnknownSoldier]

> Company does a bunch of research work, and then says "hey, you can use the research work we did if you pay us".

Patenting and/or charging to do math is idiotic. The point of having a standard is that _anyone_ could read it, and implement a working version. Standards _need_ to be free else society literally pays the price of "progress ransom"

You don't have to pay a fee to write HTML, Javascript, etc. You shouldn't have to pay a fee just to shuffle numbers around - i.e. to encode video.

Re:So who won?

[Goaway]

Google is already working on VP9, so they aren't giving up quite yet. Whether they'll manage to be competitive is another matter, but at least they're trying.

Re:So who won?

[Anonymous Coward]

"why in the hell would I want crummy looking compression unless I use at least twice the data rate?"

Because Richard Stallman said so!!

Re: So who won?

[Anonymous Coward]

If you don't know anything about this industry just shut the fuck up.

Re:So who won?

[RobbieThe1st]

Very true, but I'd go as far as to say you can charge money to /encode/ video, but should have no say over /decoding/ it. Therefor, the person encoding can choose to use a better, paid-for encoder, or a free one. The user won't care really, because they can decode it either way.

Re:So who won?

[KingMotley]

That's a popular opinion, but it's not part of the ITU charter. The ITU (and ISO) make official standards that aren't free. The ITU/ISO don't have an open source/free only perspective. Nor do they disallow competing standards.

Re:So who won?

[KingMotley]

Standards _need_ to be free else society literally pays the price of "progress ransom"

In other words, unless it's free, then people who want to use it have to help pay for the cost of developing better stuff. Just, WOW. What a concept.

Re:So who won?

[Kjella]

Well if you're rendering some cutscenes for a game and want a codec that is free to use and better than MPEG1 - MPEG2 and all newer ones are still patented - then WebM might fit the bill. I'll agree it doesn't take much to win that category though.

Re:So who won?

[node 3]

Motorola sued Microsoft, because of Apple?

You're a strange person.

Re:So who won?

[mister2au]

What does that actually mean in English?

How should make a free implementation? And how do they do that when they have to pay royalties?
Who is $BIGCO? And who do they pay a license fee to? MPEG-LA?

Are you saying companies so be allowed royalty free use of patents if the resultant software is free? Quite different than requiring free implementation

Re:So who won?

[unixisc]

Actually, he endorses Ogg Theora. But to state what he'd really say, 'It doesn't matter what the compression rates are - what matters is that this standard is actually free'.

Re:So who won?

[Anonymous Coward]

Anything else will be never go anywhere outside geek circles like Vorbis or Theora.

1) Vorbis is a sound codec not a video codec

2) Vorbis is widely used outside "geek circles" in many games and other programs that use sound.

Re:So who won?

[bill_mcgonigle]

WebM completely failed to gain any traction whatsoever against h.264, so why should it do any better against h.265?

Well, if WebM were as good as h.265, then we'd be a in a place where no hardware supports either standard and new hardware could support both standards. Right now, h.264 has hardware support and WebM doesn't, putting it at a large disadvantage.

Re:So who won?

[Divebus]

HA! True dat. And they accuse Apple of form over function!

Re:So who won?

[Anonymous Coward]

Yes, it's noticeable in that the games with codec issues are the ones that use Vorbis or Theora.

Re:So who won?

[lennier]

Company does a bunch of research work, and then says "Hey, we're now going to force everyone in the world to use our research work and pay us to do that, even if they'd prefer to use someone else's work for cheaper or free"

I forget, are we for or against authoritarianism? Depends who's paying the corporate standard committees, I guess.

Re:So who won?

[UnknownSoldier]

That's a decent trade off; maybe a good trade off might be:

Encode at lower quality (lower bitrate) = free
Encode at higher quality (higher bitrate) = $

As soon as you force people to license the codec you just shut a ton of people off from adapting it which is completely counter-intuitive.

Re:So who won?

[UnknownSoldier]

Codecs aren't rocket science, just basic computer science. (Oblg. "Brain Surgery" http://www.youtube.com/watch?v=THNPmhBl-8I )

You don't have pay a license just because you want to implement (fancy) math on a computer, which is ALL a codec is.

If companies want to license their encoder for a fee I don't have a problem with that AS LONG as it becomes free (donated to the public domain for the benefit of everyone) in 5 - 10 years. This "disease of greed and screw the public benefit" needs to stop at some point.

Re:So who won?

[Anonymous Coward]

Codecs aren't rocket science, just basic computer science.

Nonsense. Stop using exaggeration and false dichotomies to make yourself sound smart. You cannot find a CS101 course in any university which will teach an undergraduate enough to create a decent codec. In fact, no amount of pure CS is enough to invent a modern codec: perceptual encoding relies on knowledge derived from fields unrelated to CS.

You don't have pay a license just because you want to implement (fancy) math on a computer, which is ALL a codec is.

You have to pay a license because societies have generally decided (for better or worse) that things like codecs can be protected via patent law. The people and corporations who did the hard work involved in creating these codecs want to get paid for doing it, so they have taken advantage of patent law to guarantee some income.

If companies want to license their encoder for a fee I don't have a problem with that AS LONG as it becomes free (donated to the public domain for the benefit of everyone) in 5 - 10 years.

I don't even have much of a problem with that for standards-essential patents only. Just be prepared to possibly pay more in the short term, because standards developers are going to want to recover R&D costs quickly. If someone wants to develop a codec for private use and not open up any patents they use? Let them.

This "disease of greed and screw the public benefit" needs to stop at some point.

Your disease of "justify my position by claiming complex things are trivial even though I clearly know nothing about whether they actually are trivial" also needs to stop.

Huh?

[h8mx]

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.

Re:Huh?

[Anonymous Coward]

And I believe Opera still doesn't, except on Unix where it'll use the installed GStreamer plugins where available.

Re:Huh?

[maxwell demon]

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.

See? Since they didn't have it, they couldn't discard it.
In other news, lynx also never discarded support for H.264.

Re:Huh?

[Tumbleweed]

What? Firefox didn't have H.264 support until late 2012.

Unless you're talking about some non-release version of Firefox, it *still* doesn't have it. Though I think Firefox mobile does (not sure if it's the release version or not).

time to transcode again

[Anonymous Coward]

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.

Re:time to transcode again

[Anonymous Coward]

You mean you didn't encode it to WMV at some point? It's too late,t he quality is already gone.

Re:time to transcode again

[sidthegeek]

Whoooosh...

Re:time to transcode again

[bmo]

This is the Slashdot QC and calibration department. Your yearly sarcasm and humor detector calibrations are due. Please leave the detectors in the tray by the door at the end of your shift.

Thank you.

--
BMO

Re:time to transcode again

[Anonymous Coward]

Hi! I'd like to register a complaint with you, the QC and Calibration Department:

You have been doing a really shitty job lately.

Re:time to transcode again

[Kjella]

This is the Slashdot QC and calibration department. Your yearly sarcasm and humor detector calibrations are due. Please leave the detectors in the tray by the door at the end of your shift.

FYI, I think he already did.

Re:time to transcode again

[bmo]

Article summaries are part of the Editorial Department, down the hall and to the left.

Coincidentally it's in the last stall of the washroom.

--
BMO

Re:time to transcode again

[cgimusic]

I can't wait until lossless video encoding becomes practical.

Re:time to transcode again

[nabsltd]

I can't wait until lossless video encoding becomes practical.

Why? The visually perceivable differences between the source and high bit/pixel H.264 are almost non-existent.

There are generally more differences between the actual source (film/captured video/etc.) and the adjusted-before-encoding (filtering, color-"correction", etc.) source than those caused by lossy encoding.

Re:time to transcode again

[fellip_nectar]

You're missing the the point the OP was making - Repeatedly transcoding between lossy formats degrades quality each time. *You* may not perceive differences, but encoders do, and they tend to amplify those differences until they become very noticeable visual artifacts - no matter how many bits you use.

Re:time to transcode again

[AdamHaun]

There are already lossless video codecs out there. Lagarith is a recent and popular one. The problem is that they only cut maybe 2/3 off your raw file size. Ten seconds of raw 1080p video is over a gigabyte. There's just too much information there -- you have to throw some away to get reasonable compression ratios. Waiting for lossless video to be as small as H.264 is like waiting for a 200MB download for a DVD-sized Linux ISO. Sadly, it's just not going to happen.

Re:time to transcode again

[Anonymous Coward]

not likely to happen in your life time, compression gets better to give the ILLUSION of better quality, but lossless is lossless... you can't get something from nothing, the bitrate is hi no matter what, and around 100 times larger than good mpeg compression

Re:time to transcode again

[Anonymous Coward]

Pointless without a gold-plated HDMI cable, though.

Re:time to transcode again

[ArsonSmith]

I don't think anyone is waiting for lossless codecs to get smaller, they are waiting for the hardware to get bigger. It happened to compressed formats for music in the 90s and video in the 00s, now the teens may start to see losslessly compressed formats rule.

Re:time to transcode again

[Tough Love]

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.

A videophile maybe, but a clueless one indeed. You lose quality on each transcode, you don't gain any.

Re:time to transcode again

[Tough Love]

Hah, I missed the sarcasm tag. Oh there was no sarcasm tag. Nice troll.

Re:time to transcode again

[Anonymous Coward]

Wow you're stupid.

I assume you're one of the people who fucks things up on this site by modding obvious jokes "troll".

Re:time to transcode again

[nabsltd]

Repeatedly transcoding between lossy formats degrades quality each time. *You* may not perceive differences, but encoders do, and they tend to amplify those differences until they become very noticeable visual artifacts - no matter how many bits you use.

If you need to work with original content to edit it before the final compression for consumption, then you need lossless. But, there are plenty of lossless formats that will work for that, and some are compressed. If you dedicate 1TB or so to your edit workspace, you won't need to use a compressed format unless you are working with the entirety of a modern 2-hour movie. I learned this when I accidently forgot to choose a compression method when re-encoding some TV shows at 720p, and it took over 4 hours of uncompressed video before I ran through the 500GB disk space that was free.

For anything where you have access to the master (original Blu-Ray, home videos, etc.), you don't really care about lossless, as you will do any edits and then compress the final. If you want to do some minor tweaks to a MPEG-2 or H.264 video where it would take too long for a full re-compress, or you just don't have access to the original, you can use VideoReDo and only re-compress frames in the GOP that contains the edit points.

Re:time to transcode again

[KingMotley]

I can't wait until lossless video encoding becomes practical.

Are you waiting for JPEG images to die as well? I bet you love them 100MB download per page websites too.

Re:time to transcode again

[Anonymous Coward]

excuse me sir, but RMVB beats out WMV every time.. best quality ever.

Re:time to transcode again

[tlhIngan]

I don't think anyone is waiting for lossless codecs to get smaller, they are waiting for the hardware to get bigger. It happened to compressed formats for music in the 90s and video in the 00s, now the teens may start to see losslessly compressed formats rule.

The storage is already here - 4TB drives can hold a useful amount of lossless video. A 1080p video frame is around 6MB uncompressed, at 30fps that's 180MB/sec. If you want true 1080p60, that's 360MB/sec, or about 3 seconds a gigabyte. A minute takes 20GB, 1TB can hold 50 minutes. 4TB can hold 200minutes, or just over 3 hours worth of uncompressed 1080p60 video.

The big problem has been the bandwidth required - lossless video requires a ton of bandwidth - it's why 4K cameras use SSDs for storage - spinning rust cannot maintain sufficient data rate. Or why video editors tend to be the biggest users of RAID-0 (striping, no redundancy) storage.

And most cameras don't use lossless to begin with - a 4K frame quaruples the data rate (turning our 4TB drive into a still-useful 50 minutes of video storage), but we're talking about a massive 1.4GB/sec. The ever-popular RED cameras use SSDs, and proprietary REDcode codecs in order to be able to keep datarates down enough for an SSD.

Want to go lossless? You'll need to go back to film.

Re:time to transcode again

[mister2au]

compression gets better to give the ILLUSION of better quality, but lossless is lossless

What a stupid comment ... of course, better compression algorithms can give better quality (than an inferior algorithm) for a given size - its not an illusion

Re:time to transcode again

[ArsonSmith]

even with bandwidth having 3 hours on a 4 TB drive isn't going to cut it. I have nearly 1000 movies and tv shows on my 3TB drive. Once we have PB sized drives with GB/sec transfer rates then we will be talking.

Re:time to transcode again

[gravis777]

Oh, that is not the way to go. You ought to see what you can do with VHS. Capture with MJPEG to Cinepak, then export to VCD. Rip that to Indeo 4, then convert to Indeo 5. Import into Adobe Premiere and run some filters on it. Export to SVCD. Rip and upconvert the SVCD into MPEG2 720x480 and export to a DIVX file. Convert to WMV with Windows Media Encoder. Import back into Adobe Premiere, add a few more filters, export to Quicktime. Upload to Youtube, using their video stabalizers and automatic filters. Use a Youtube grabber to download the FLV. Use AnyVideoConverter to convert to MP4 h264. Run through MovAVI to convert to 3D and upscale the image. Upload back to to Youtube, run through some more filters, then download the MP4 file. Upscale to 8k, convert to h.265.

What, each one of those codecs is better than the previous, surely your video must look amazing by now!

Re:time to transcode again

[RalphTheWonderLlama]

After depositing entries into the Inbox, please press the lever to send them on.

Dhurum

[ickleberry]

Does this format have and built in DRM (pronounced 'Dhurum") or other nasties?

Re:Dhurum

[rsmith-mac]

Nothing more than H.264 had. DRM is implemented at the container level, not the bitstream level.

I hate the dark cloud over software advances.

[Irick]

I want to be excited about this but people keep reminding me that software patents suck.

Re:I hate the dark cloud over software advances.

[loufoque]

Good thing software patents don't exist in most of the civilized world then.

Re:I hate the dark cloud over software advances.

[Anonymous Coward]

Sorry, these patents cover the hardware/device level. The royalties will be included in your next computer & phone no matter where you live.

Re:I hate the dark cloud over software advances.

[Anonymous Coward]

its funny that this so called civilized world also puts people in prison if their speech 'offends' someone or if they dare to defend themselves. the US is not the only western country with idiotic policies.

Mp3

[bstrobl]

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.

Re:Mp3

[Anonymous Coward]

This is for video. Major implications for mobile video and 4K/8K post-HD stuff.

Re:Mp3

[Gaygirlie]

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.

MP3-files are small enough to be streamable perfectly well even on really slow connections, but video files ain't small. A 2-hour, 1080p video file with any kind of a remotely-acceptable quality will weigh in at 4GB+, and well, it sure ain't streamable over very slow connections. Not to mention the fact that bandwidth costs money. Ergo, any developments that result in higher quality at the same size or similar quality at a smaller size are certainly welcome, both for consumers and for content-producers.

As a thought-experiment, let's assume that this or that TV-series I was watching on Netflix weighed in at 1.5GB for a 1h episode, and I watched 15 episodes in a month. That'd be 22.5GB of data. Now, if the move to a new codec reduced filesizes by 5% we'd end up with ~21.4GB of data -- that's already one gigabyte in savings. Now, multiply this with e.g. 200 000 users, what do you see?

Re:Mp3

[Anonymous Coward]

If you were smart the first time, you ripped all your music to a lossless format. I ripped all my CDs into flac, and when I wanted to burn CDs for my car's player, which read mp3, I used ffmpeg in a loop to transcode all of it into a copy of mp3, and burned that to disc. Time to convert? about 10 minutes to get the loop syntax right, and then I went to bed. Took me longer to actually burn it.

Then I got an android phone, and it could play vorbis, which is quite superior to mp3. So I changed that loop from 'ffmpeg -acodec mp3' to 'ffmpeg -acodec libvorbis' and reran it, and went to bed.

Obviously won't work as well for video since lossless codecs there aren't as good, and you're talking MUCH bigger files, but music hasn't been an issue for some time.

Re:Mp3

[LordKronos]

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.

MP3-files are small enough to be streamable perfectly well even on really slow connections, but video files ain't small. A 2-hour, 1080p video file with any kind of a remotely-acceptable quality will weigh in at 4GB+, and well, it sure ain't streamable over very slow connections. Not to mention the fact that bandwidth costs money. Ergo, any developments that result in higher quality at the same size or similar quality at a smaller size are certainly welcome, both for consumers and for content-producers.

As a thought-experiment, let's assume that this or that TV-series I was watching on Netflix weighed in at 1.5GB for a 1h episode, and I watched 15 episodes in a month. That'd be 22.5GB of data. Now, if the move to a new codec reduced filesizes by 5% we'd end up with ~21.4GB of data -- that's already one gigabyte in savings. Now, multiply this with e.g. 200 000 users, what do you see?

Apparently you don't remember it, but at one time, MP3 files weren't small either. I remember it taking about an hour to download a good quality MP3. And there was streaming, too. Things like Real Player provided lower quality, higher compressed versions that were more suitable for streaming. Then do you know what happened next? Did Real Player and stuff like it win out? Nope. I'll give you a hint...the MP3 files didn't get any smaller.

Connections got faster, and bandwidth got cheaper. Much like those days for MP3, today good quality h264 files are a bit cumbersome, but I can easily download them in an hour or 2 with a typical (not even high end) consumer level internet connection. And today there are ways to get lower quality, more highly compressed version that can stream a fairly good quality HD video in real time. Give it another 5 years and the problem will easily solve itself without replacing every single piece of hardware and re-encoding every existing file.

Re:Mp3

[Kjella]

Why bother re-encoding a complete music library from mp3 even if vorbis/aac is clearly the superior codec?

You're asking the wrong question, the right question is how many have FLAC copies of all their MP3s? Because I hope you weren't seriously suggesting they should re-encode from the MP3 files. I think you will find that many people have never even heard of FLAC and even if they did few tools have made it easy to create dual FLAC/MP3 rips of a CD, least not any the average person would have heard about. Assuming he didn't just download those MP3s in the first place and isn't about to chase down different copies for a microscopic space savings - maybe percentage-wise it's great but even thousands of songs will fit in a tiny corner of a modern HDD.

Video on the other hand is still huge. 60 BluRays to a 3TB HDD is not much, 4K is coming and for YouTube, Netflix etc. bandwidth costs are still a huge cost - far more than say Spotify. If people are maxing their cap on the Internet connection it's likely to be because of a lot of streaming video. Of course there's a huge broadband roll-out to give people more bandwidth as well, but this is not an either-or situation. For broadcasters as well this is a huge upgrade, more compression means being able to send more TV channels in a limited frequency band. As far as I know, all US channels still broadcast in MPEG2 and H.264 wasn't enough to make them change, maybe HEVC will be? At least any country looking for a new system would seriously consider it.

Re:Mp3

[Buzer]

Old content will stay in h264, new content will be released in h265. For when that switch happens depends on market. Anime fansubs have been early adopters for pretty much all new technologies relating to non-streamed video. I except them to start using it pretty much right after some kind of x265 will come out. Other markets will make the switch slower (or they will just keep using both) as it requires upgrading the consumers hardware/software.

Re:Mp3

[ArsonSmith]

Wow, are you saying that if I multiply 5% times 200,000 users I would get, something like at least 5% of their usage? That's amazing.

Re:Mp3

[Anonymous Coward]

The MP3 encoders also got better though, so the quality isn't nearly as bad as it used to be. H.264 encoders also keep getting better. You don't necessarily need a new format to improve things.

Re:Mp3

[Anonymous Coward]

Hmmm, not quite sure, but I think my home theatre plays OGG, and I am certain it plays FLAC.

Re:Mp3

[Anonymous Coward]

i gotta call bullshit on that last part. i don't see it resolving itself anytime soon. internet speeds have remained stagnant over the last decade, without increased infrastructure or the internet providers stopping throttling, nothing will change in the next five years or so. because money.

Re:Mp3

[LordKronos]

Really? Must be your cable provider. In the last few years, my cable provider (WideOpenWest) has given a free upgrade from 8Mbps to 16Mbps (and in the 5 years before that we went from 4Mbps to 8Mpbs), and introduced new 30Mbps and 50Mbps plans. Comcast has introduced 100Mbps a plan in many areas. Google has their first Gigabit city. I've heard a number of stories of municipals setting up their own internet service with speeds between 20Mbps and 100Mbps. Verizon Fios has new plans of 50Mbs, 75 Mbps, 150Mbps, and 300Mbps.

It's happening. It won't be overnight, but eventually even your cable provider is gonna have to improve to keep up. If they don't, someone like Comcast or Verizon will be all to happy to move in and steal the market from under them.

Re:Mp3

[Anonymous Coward]

same ac you replied to.

i apologize. yes, you are correct. it is my cable provider that gives me such a jaded view. where i live, comcast is the only game in town for a somewhat decent internet. and speeds haven't increased at all in over ten years. although, of course, the prices have.

i am in the wrong using my sample size of one. but the feeling i get (with no actual proof) is that they will continue to offer the same exact service at ever increasing prices while making sure that faster speeds are equally expensive through collusion.

fios is incredible. they have been making incredible progress as far as speeds go. i don't know anything about their pricing, but i, once again, feel pretty sure that the price per Mb/s while stay the same across the board. (i may be totally wrong on that, as i haven't even looked at their pricing model)

i just don't see internet providers actually competing because there seems to be so much money in their own little monopolies.

Re:Mp3

[LordKronos]

Another thing that plays into it: are you in a major metro area, or more rural? Rural areas are always going to lag behind. The first player in can justify it because they get 100% of the market. After that, additional service providers will only see a fraction of that return, thus it's not worth it to start up there, and thus the first player gets to enjoy their monopoly for a long time (so no incentive to upgrade). So, yeah, they'll always stay behind, but in the context of this thread (whether there's a considerable benefit to replacing one codec with another and having to replace/retool all the hardware), those rural areas are insignificant, since stuff will mostly be designed around the majority of the population this lives around major cities and mostly will get upgraded service over the years.

Re:Mp3

[cthulhu11]

MP3-files are small enough to be streamable perfectly well even on really slow connections, but video files ain't small. A 2-hour, 1080p video file[/quote] Point taken, but of course almost nobody provides 1080 content.

Apparently you don't remember it, but at one time, MP3 files weren't small either. I remember it taking about an hour to download a good quality MP3.

Via PSTN dialup?

And there was streaming, too. Things like Real Player provided lower quality, higher compressed versions that were more suitable for streaming. Then do you know what happened next? Did Real Player and stuff like it win out? Nope.

... partly because the Real software sucked really hard and failed to deliver what it promised. Instead of "streaming" we got interminable "buffering..." messages punctuated every 20 seconds with a brief snippet of actual playback. And then Real removed features from the player so that existing .rm files wouldn't play with later versions of the software.

i gotta call bullshit on that last part. i don't see it resolving itself anytime soon. internet speeds have remained stagnant over the last decade, without increased infrastructure or the internet providers stopping throttling, nothing will change

Don't equate low-end last-mile residential providers with "internet providers". Trust me, real provider speeds have increased substantially over the last decade. Residential speeds have too, but part of why we see no widespread efforts to bring even faster connections to homes these days is that most customers in areas that can get at least *DSL already have more speed than they know what to do with.

I HAVE a PREDICTION!

[Anonymous Coward]

The Next standard will be H.266! I'll come back in 4 years and gloat when I'm right.

Re:I HAVE a PREDICTION!

[Anonymous Coward]

Bah. If you thought h264 was had bad patent issues, wait for h666. OTOH, why worry, AC's will probably be extinct by then anyway!

Re:I HAVE a PREDICTION!

[maxwell demon]

Actually, H.666 will be quite cheap. All payment they demand will be your soul.

Scene releases

[Anonymous Coward]

When will scene releases switch? That's all that matters.

Re:Scene releases

[mister2au]

As soon as 1 or 2 mainstream players support it ... my bet would be mid-to-late 2013

Re:Scene releases

[Anonymous Coward]

yeah right.... h264 was published in 1999 it took years for even the commericial players to play it. The commericial players are driven by the market demand. So it won't be until there is good demand. The free-ware players come much later once there rare enough people using the format.

Secondly there are some interesting technical things that mean the gap between the official and free codecs will be even bigger. AVC for example runs at about 1/4 to 1/10th the CPU compared to say whats thrown into VLC player. h265 seems to be even more slick (ie. parts of it are backward written from specific code they have already optimised - which makes it very hard for open source to compete - especially when most open source values code readability above actual performance).

"this attempt never materialized"??

[stenvar]

They also included it in Chrome, with the intent to replace H.264, but this attempt never materialized.

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.

Re:"this attempt never materialized"??

[Anonymous Coward]

WebM doesn't have the performance (in terms of bitrate vs quality) to compete with H.265.

Re:"this attempt never materialized"??

[Rockoon]

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.

WebM could barely compete with H.264, so how the hell is it going to compete with H.265 which is going to offer the same quality at H.264 but only use about half the bitrate?

If Google could have improved WebM this much, they would have.

Re:"this attempt never materialized"??

[westlake]

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.

WebM is a distribution codec for YouTube. H.264 is core technology in digital television.

Theatrical production. Cable, broadcast and satellite distribution. Home video. Industrial applications... The list goes on and on and on.

The licensors of H.264/HEVC are global giants in R&D and manufacturing. Philips. Samsung, Mitsubishi. Panasonic. Toshiba. The 1181 H.264 licensees operate on more or less the same scale. The standards they adopt are the standards which stick.

Re:"this attempt never materialized"??

[Anonymous Coward]

The current WebM standard uses the VP8 video codec.
Google is currently working on VP9, which is supposed to include major improvements to the quality/bitrate.

It's still in development, and I haven't seen much in the way of independent testing yet, but going by the statements of the developers it's a next-gen codec and should at least beat H.264 and be competitive with H.265.

Re:"this attempt never materialized"??

[stenvar]

Which part of "video standards aren't replaced overnight" went over your head?

You can look at PNG/JPEG to see how this is likely to play out, except that the incentives to move from H.264/5 to WebM are actually stronger for many people.

Re:"this attempt never materialized"??

[Anonymous Coward]

Not everything has to be the "best" to be the best. If your consumer base doesn't notice the difference between webm and H.265 and the bandwidth saved doesn't offset the royalties or it isn't your bandwidth or it makes a lot of sense to go the direction of webm. I think in a lot of cases webm is the best choice.

Re:"this attempt never materialized"??

[Anonymous Coward]

The current WebM standard uses the VP8 video codec.

WebM is defined specifically as VP8 video streams and Vorbis audio streams in a Matroska container.

There cannot be another codec used while still being WebM. Google can work on a new codec, but it cannot be used in WebM because that would break everything. WebM is not a container.. WebM is a specification.

Re:"this attempt never materialized"??

[Anonymous Coward]

WebM could barely compete with H.264, so how the hell is it going to compete with H.265 which is going to offer the same quality at H.264 but only use about half the bitrate?

Video encoding is currently under the "it's free as long as your vid is unpopular" umbrella. From a content creator point of view (esp. as a dev who is implementing a video/audio encoder from scratch to turn in-engine playback/record into videos uploadable to youtube, etc.), implementing H.264/5 encoding isn't even on the table as a "maybe" option due to licensing BS. I think it's silly to call the fight of WebM vs H.264, especially from a content creator perspective. From a consumer perspective, I think it's far less important, and thus the argument is far weaker.

TL;DR: Bandwidth is cheap. The format war is fought in the authoring world, so what matters most is content creators & authoring tools.

If Google could have improved WebM this much, they would have.

[citation needed]

Re:"this attempt never materialized"??

[Anonymous Coward]

The Internet generations lives in its own bubble of Google products and startup dreams. The world out there is a bit different.

Re:"this attempt never materialized"??

[Anonymous Coward]

Right, so they'll call it WebM 2 or whatever.

The point is, when people say "let's hope that WebM can compete with H.265", they probably mean "let's hope VP9 can compete with H.265", while when they say "WebM could barely compete with H.264", they mean "VP8 could barely compete with H.264".

(BTW, the audio codec for next-gen WebM will probably be Opus, which by all accounts is excellent.)

Re:"this attempt never materialized"??

[Anonymous Coward]

Google HAS been improving WebM. They have cut the bitrate about 40 percent for the same quality. They are still making it better and that's just with changes to the encoder. They also have some changes set aside that would require a format change, but that hasn't been rolled out yet. There are also free hardware implementations available now that are very power-efficient. They list some 80 hardware makers who support it. I would say WebM is about ready to compete with H.265 for adoption as the next popular codec. All Google has to do is throw the switch on YouTube and the world will change. I suspect they've been holding out so long to ensure that change is seamless for as many people as possible. There are many devices supporting WebM whose users have no idea yet. Android has supported it in software for years, and new phones have hardware support. But my crystal ball is not perfect, we will have to see how this plays out.

Re:"this attempt never materialized"??

[Anonymous Coward]

Tell you what, why don't you stop using this "free shit". You can start by getting off Slashdot, because without all this "free shit", you wouldn't have your phone, your PC, your Internet connection, or websites like Slashdot.

Re:"this attempt never materialized"??

[Anonymous Coward]

because without all this "free shit", you wouldn't have your phone, your PC, your Internet connection

Last I checked my phone, my PC, and internet connection -- none of it was free.

Patent-encumbered standards are stupid

[Nimey]

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?

Re:Patent-encumbered standards are stupid

[xswl0931]

The standard IS open in that during definition of it anyone (paying to be a member) can contribute, provide feedback, and vote. If you meant free as in beer, they could have required that, but then none of the corporations that did the R&D would have participated and we'd have many "standards" and not just one.

Re:Patent-encumbered standards are stupid

[Rockoon]

Its because they want something that is near the best technology possible at this time, and that means dealing with the people that do actually have technology that is near the best possible at this time. H.265 is a very large improvement over H.264 (about 50% of the bit rate for equal quality) and nobody in the "open" world can do that.

This is a huge upgrade for any business pushing digital video through wires and radio waves. Even in the case where encoder and decoder licenses are a large cost, they will still win big with this sort of upgrade. This effectively doubles their capacity with only a software change.

So no, patent-encumbered standards arent stupid. Adopting demonstrably very-far-from-optimal standards is stupid.

Re:Patent-encumbered standards are stupid

[Anonymous Coward]

That was stupid though. There are companies which have an interest in these improvments beyond profiting off of the royalties.

Re:Patent-encumbered standards are stupid

[lingon]

All of those patents are most likely incredibly trivial and all companies and organizations that sucessfully lobbied them in, did so not for their technological benefits but to make sure their patents were as widely used as possible.

If the ITU were to demand patent-free standards, they would be just as good but without the royalties.

Re:Patent-encumbered standards are stupid

[Rockoon]

Did you just theorize that it was trivial to improve H.264 to use half the number of bits for a given video quality?

I'm simply amazed at the depths of the dream world that some people live in.

Re:Patent-encumbered standards are stupid

[LordKronos]

H.265 is a very large improvement over H.264 (about 50% of the bit rate for equal quality)

According to wikipedia, it's 35.4% smaller
http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Coding_efficiency

Re:Patent-encumbered standards are stupid

[amorsen]

Anyone who believes they can describe the efficiency difference between two video codecs as one percentage with 3 significant digits needs their head examined.

Re:Patent-encumbered standards are stupid

[mrnobo1024]

This is the ITU, the same geniuses behind the "leap second" that crashed computer systems all over the world last June (because god forbid our clocks should ever be out of synch with the Earth's rotation by more than one second - never mind that given the way time zones are set up, many places are off by over an hour anyway). I'd be surprised if they even know what a patent is let alone why it's a bad thing to have on a standardized file format.

Re:Patent-encumbered standards are stupid

[Anonymous Coward]

Kill yourself.

Re:Patent-encumbered standards are stupid

[Anonymous Coward]

If the ITU were to demand patent-free standards, we wouldn't have any video at all, and all images on the internet would be in .bmp format

Fixed that for you.

Re:Patent-encumbered standards are stupid

[LordKronos]

Apparently you don't know what the word average means, or how significant digits are used. The thing being measured has no impact on the number of significant digits you can use. It's purely determined by the precision of your measurements.

Re:Patent-encumbered standards are stupid

[amorsen]

I don't have anything to add to what I wrote above. No one has defined a metric that can meaningfully distinguish between to video codecs to 3 significant digits.

Amazing how you twisted that.

[Anonymous Coward]

No, the companies said "You HAVE TO use these results of our research NOW PAY US!!!!".

Re:Amazing how you twisted that.

[Anonymous Coward]

Should you CHOOSE to use this technology.

Amazing how you twisted that.

Re:Amazing how you twisted that.

[peppepz]

You don't choose to "use" standards. You are forced to implement them either by government regulation or interoperability needs. See what happens with the FAT file system: it's the result of an insignificant research effort, it is itself extremely poor technology, yet every device manufacturer is currently forced to implement it, and therefore needs to pay money to Microsoft.

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.

Re:Amazing how you twisted that.

[maxwell demon]

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.

Re:Amazing how you twisted that.

[KingMotley]

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.

Re:Amazing how you twisted that.

[peppepz]

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.

Re:Amazing how you twisted that.

[Anonymous Coward]

Regading FAT, you are right, it _is_ simple technology. FAT32, however, has during those 40 years accumulated plenty of stuff we technical folks like to call "kludges". A modern system rewritten from scratch with simplicity in mind would simultanously be both simpler _and_ more effective, and not by a small margin.

Re:Amazing how you twisted that.

[KingMotley]

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.

Re:Amazing how you twisted that.

[peppepz]

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.

H.265 will gain traction in video conferencing

[Danathar]

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)

Re:H.265 will gain traction in video conferencing

[MtViewGuy]

I also think that H.265 could find its way to satellite TV broadcasting, because its lower bandwidth requirements for 720p/1080i resolution video means they can add in more channels per satellite.

Re:H.265 will gain traction in video conferencing

[Luckyo]

First adaptation, as usual, will be by HQ rip groups and anime fansubbers. These people pride themselves in being on the cutting edge and implementing stuff that isn't implemented anywhere in hardware yet. They were the guys who moved from h.264 high profile to h.264 10 bit high profile when h.264 hardware support started to become prevalent. They were the ones who moved to h.264 when divx hardware support became prevalent. Etc.

Funnily enough, it was the same for h.264, divx/xvid and so on. Frankly I wouldn't be surprised if many of the guys encoding that stuff actually work in the industry and use their "hobby" as a testbed for new encoding techniques and methods before they go to mass production.

Re:H.265 will gain traction in video conferencing

[wonkey_monkey]

I also think that H.265 could find its way to satellite TV broadcasting, because its lower bandwidth requirements for 720p/1080i resolution video means they can add in more channels per satellite.

You might be waiting a while. We're still stuck with MPEG2 for our SD channels, over DVB-T and DVB-S.

Re:H.265 will gain traction in video conferencing

[Anonymous Coward]

Just having the encoding doesn't mean they can do it. They'll need to update the hardware on the subscribers side for decoding H.265. That's going to take a lot of $$$.

Re:H.265 will gain traction in video conferencing

[aaron44126]

Or maybe they can keep the bandwidth the same (or not lower as much as they could) and instead take advantage of higher quality at the same bitrate... so that the channels don't look so terrible with compression artifacts all over the place.

Re:H.265 will gain traction in video conferencing

[Anonymous Coward]

It sucks to be you. We never had anything other than h264 over dvbt.

Re:H.265 will gain traction in video conferencing

[Anonymous Coward]

Wrong. You have it backwards. H.265 is an order of magnitude more computationally complex, so realtime will see the least benefits (given the realtime constraint) and offline encoding the most benefit. Also, a substantial amount of the compression gains come from being able to operate on larger macroblock sizes, and there are likely of more benefit for higher resolution material. So, expect this to be of most benefit for 1080p+ streaming video content.

Re:H.265 will gain traction in video conferencing

[Guspaz]

I expect we'll see services like Netflix jump on the bandwagon pretty fast. They already produce multiple copies of their videos in different codecs to cater to different device capabilities. If memory serves, they do VC-1 for the desktop client, low bitrate h.264 for the mobile clients, and high bitrate h.264 for the STB/console clients.

Migrating platforms which can support it to h.265 will provide them with immediate savings. There aren't that many of them, but the PS3 happens to be their flagship and development platform (it's the single most popular Netflix device so they launch new features on it first), and it can probably handle h.265 in software. It's a dumb CPU design for general use, but it excels at this sort of thing.

Re:H.265 will gain traction in video conferencing

[jedidiah]

Changing codecs is going to require outfits like Dish and DirecTV to replace all of the end user hardware. I'm not convinced that h265 is enough of an improvement for them to consider this.

The more legacy users you have, the harder it is for you to get buy-in on a new digital format. Incremental improvements will continue to be a harder and harder sell to people with legacy content and legacy equipment.

Re:H.265 will gain traction in video conferencing

[Anonymous Coward]

I work in satellite video. This is partially true. Hardware developed in the last decade or so all implements reconfigurable decoders so would likely be able to handle the changes in H.265. The software, on the other hand, largely did not facilitate this. Newer devices built in the last two years (still in development), however, do facilitate reconfiguring the decoders with a driver update.

Re:H.265 will gain traction in video conferencing

[Anonymous Coward]

Yep. The new satellites will have card that can decode H.265. When the old satellite decoding H.264 wears out... in about 11 more years. Oh, they could rush out and spend $200 million on a new satellite right away and another $150 million to put it into orbit. Or they could just use the old satellite for 11 more years.. It only costs about $20 million per year to operate a satellite.

Re:H.265 will gain traction in video conferencing

[MtViewGuy]

Because H.265 will has (I believe) half the bandwidth requirements of H.264, DirecTV or Dish Network could either cram in more channels or keep the current channel allocations but at MUCH higher video quality.

please prove that statement.

[Anonymous Coward]

because it sounds like it's made up out of hope and pray.

BD+

[tepples]

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.

Re:BD+

[nabsltd]

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.

Although "transform the audio and video output" is listed as an option of BD+, it doesn't work the same way as most humans would parse that description. Based on this, it's just another way to encrypt the full .m2ts stream.

If it actually altered the video after decompression but before output, it would be impossible to rip a Blu-Ray losslessly with that protection, as you would need to decode the H.264 stream, apply the BD+ operations, then re-encode those frames to put back into the ripped stream. Note that you could never fully protect audio this way, as although you could apply the same sort of transformation, the audio stream isn't always decoded by the Blu-Ray player.

In addition, in order to alter the uncompressed data, it would require that every Blu-Ray player use exactly the same H.264 decoder with exactly the same options and only apply video alterations after BD+ is done with the data. This is a problem, because there are parts of H.264 decoding that are optional because they take CPU power and may not hurt video quality enough to require them.

Re:BD+

[Tough Love]

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.

Blu-ray is generally pathetic and an altogether unpleasant experience for the user with slow startup and numerous unskippable ads and threats, just to name two deficiencies.

Re:BD+

[tepples]

If it actually altered the video after decompression but before output, it would be impossible to rip a Blu-Ray losslessly with that protection

Exactly as planned.

In addition, in order to alter the uncompressed data, it would require that every Blu-Ray player use exactly the same H.264 decoder with exactly the same options and only apply video alterations after BD+ is done with the data.

I was under the impression that the transformations didn't need to depend on bit-perfect output from the video decoder. Just guessing, but they could involve color space modification, rotation, flipping, cutting and pasting, bending (remember old scrambled channels from the VideoCipher II era?), and the like.

Re:BD+

[nabsltd]

If it actually altered the video after decompression but before output, it would be impossible to rip a Blu-Ray losslessly with that protection

Exactly as planned.

Since this would effectively stop ripping, I'm pretty sure if it were possible while still letting Blu-Ray players play the movie, it would already have been done.

I was under the impression that the transformations didn't need to depend on bit-perfect output from the video decoder. Just guessing, but they could involve color space modification, rotation, flipping, cutting and pasting, bending (remember old scrambled channels from the VideoCipher II era?), and the like.

First, they have to be simple, because of the limited power of the BD+ virtual machine, so anything that involved serious memory moves would be out. Color and pixel value would be pretty much the limit.

Depending on much the decoding varies from the reference, there might be some seriously noticable artifacts, especially if the scrambing was enough to make the picture unwatchable. Try something as simple as lowering the saturation even a tiny bit on one frame in the middle of stream, and it will "flash" as different to a viewer. You'd probably have to alter at least 5% of frames to cause enough annoyance when watching a copy, which would be 1 frame/second on average. With different kinds of changes to different parts of the image, it would be very noticable. Without perfect reconstruction, that would result in a lot of discs returned to stores.

Immigration

[tepples]

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?

Re:Immigration

[loufoque]

Good question. I don't know. Realistically speaking, I wouldn't count on European countries refusing extradition to the US.

Re:Immigration

[tepples]

Mostly I'm more interested in whether they'd offer work visas to affected Americans begin with.

Re:Immigration

[loufoque]

Going to the EU doesn't require a visa for American citizens.
You can regularize your situation by applying for asylum once there, but if you're in a good country they won't deport you anyway (unless there is an extradition request).

kill it via no support from firefox/opera/chrome

[Anonymous Coward]

We need to fund developments of the webm standard to get it up to speed. With all the money Mozilla, Google, and even Opera is bringing in you would think that wouldn't be that terribly difficult. Start hiring/stealing the people with the know-how.

Another patent grenade from the ITU

[Anonymous Coward]

In good ITU tradition, the new standard is a patent minefield.

Moronic Article

[Anonymous Coward]

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.

Re:Moronic Article

[jedidiah]

> The advantage of H265 (and H264) to end users is clear. Tiny, extremely energy efficient, hardware circuits can handle the video decoding

That's all well and good, but that's supposed to be what the advantages of h264 are and we've already got that and tons of legacy equipment and content.

On the other hand, most people are going to be hard pressed to notice any reason to want 4K given that BluRay is already a tough sell with anything much beyond a 1:1 viewing distance to screen size ratio.

Re:Moronic Article

[Anonymous Coward]

If people want to be activists over the royalty situation, it should be with this goal.

A goal. Not the goal. The goal is to get rid of patent encumbered software and the leeches who profit from them.

Encoders, and encoded video (including streamed) should be royalty free.

Decoders should be royalty free also.

Only the decoders (hardware or software) should pay a royalty.

No they shouldn't.

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 organization of charges is a minor detail. This is a profit maximization situation. They will charge whatever they can to maximize their benefit and, because it's basically zero-sum (a cartel with no competition), thus minimize the general population's net benefit.

Re:Moronic Article

[Anonymous Coward]

while you are busy calling people morons, you espouse a system that makes no sense to the very people that have to support the development of it to begin with. Encoders are the most valuable part of the food chain when it comes to video compression. They are the hardest to implement, contain the most clever ideas, the most effort when it comes to optimization, and quite simply, they are where the magic is. There is a reason that the standards are written from a decoders point of view. The decoders are what the encoders must conform to as it does not matter how you arrive at the encoded video as long as it can decode with the reference decoder. Decoding should be free (and is for the most part) specifically because it is A. Much easier to do a decoder and B. much more documented from a standards perspective, and C because it is the point where it reaches the consumer.

    The other half of your argument that encoded video should be free and the decoding should cost makes no sense whatsoever. You would rather that people who consume video somehow subsidize the standard when in fact it is encoding it into the standard that creates the opportunity to begin with and puts the cost squarely on the provider instead of the consumer. Why should the consumer pay more to watch video when they already have to pay for delivery? Pot meet kettle your argument makes no sense.

Re:Moronic Article

[Anonymous Coward]

Bullshit, the x264 developers (in this case Garret-Glaser aka DarkShikari) did no such thing. He surmised that their were similarities between the implementations when examining the source code but he had NO idea if they were patentable, and if so, patented, and if so, who they were patented by. Not surprising since Garret-Glacer by his own admission doesn't give a shit about patents.

On2 which Google bought also has lots of video compression patents, patents which standards like h.264/h.265 are just as likely to violate. Back when VP8 was released we heard the same bullshit about how MPEG-LA was going to sue, all that happened was that MPEG-LA did some sable-rattling when they 'asked' patent holders to get in touch with them with patents they thought VP8 could infringe upon which could be placed in their 'pool'... (wait, wasn't VP8 already infringing on TONS of patents according to you? Why would they need to beg others for patents?)

Now Google is developing VP9, the successor to VP8 which is going to compete with h.265 in terms of quality, are you seriously saying that Google would pursue this if they were ripe for patent lawsuits, or if they 'only wanted to transfer millions to the owners of the company' as you claimed?

Apart from outright lying about the supposed patent discovery by the x264 devs, your arguments have no logic.

Re:Moronic Article

[Anonymous Coward]

http://www.itu.int/rec/T-REC-H.264-201201-I/en

What was that about having to pay to get a copy of the H.264 standard???

Re:true sceners dont use h264

[Guspaz]

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."

but the patent issues plaguing H.264 remain

[93 Escort Wagon]

Yeah, those issues have certainly prevented h.264 from taking off. Luckily WebM adoption has roared out of the gate... *cough*

Missing the forest for the trees

[realinvalidname]

Barely a word about the actual nature of the codec in the summary, but lots and lots and lots about patents.

Re:Missing the forest for the trees

[Anonymous Coward]

in a nutshell, you could cram three or four 1080p subchannels in one atsc broadcast channel instead of one 1080p plus maybe one 720p or two 480s. cable companies could squeeze seven or eight 1080p streams into one distribution channel. roughly a 70% bit savings over mpeg2 is a really big deal..

now there's too much mpeg2-based hdtv equipment out there to do yet-another transition. the digital tv switch was too early, and not flexible prior to implementation to allow for updated technologies. mpeg2 atsc was developed in the early 90s. if it had held off for at least a couple years, we could conceivably at least have h264-based hdtv (which has been in atsc standard since 2008) in the u.s. as standard instead of mpeg2. the digital transition in 2009 was fucked from the start.

i still don't get the h.264 thingy

[Anonymous Coward]

modern gpus/blu-ray players/capture cards that do h.264 encoding/decoding should have licensed the tech from the get-go, right? besides old stuff, which may or may not rely on less honest software, that will be phased out in due-time, what is the problem? how does it differ from, say, mpeg-2 licensing? did they give out for free and may or may not (they say not) want to come collecting?

Bullshit

[Anonymous Coward]

Thanks a lot apologists for screwing things up for the rest of us. WebM wasn't the greatest thing, but at least it's royalty free and available for any platform willing to port it. h.264 was never royalty free and never would be. They were just kind enough to only charge 2 times for a file that's encoded, streamed and decoded. Something which TFS should have made clear.

Standards should be free to use.

Awww...Liddle HD-DVD Fanboy Still Crying

[Anonymous Coward]

Poor liddle faggot...

Still crying over your shit HD-DVD format taking a dirtnap...

Re:Awww...Liddle HD-DVD Fanboy Still Crying

[Tough Love]

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.

Why did it fail?

[Anonymous Coward]

Because of Apple Fanbois.

Because the FUD about "h264 is accelerated in hardware, WebM can't be, and all the internet will crash under the load of having to retranscode".

Because MPEG-LA continued to threaten everyone who dared look at it with a protection racket and FUD about "WE OWN VIDEO COMPRESSION".

Indeed, it failed to get traction for no good technical reason.

Solely for marketing reasons.

Re:Why did it fail?

[shutdown -p now]

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?

Xiph also working on next-gen codec

[Anonymous Coward]

Xiph are also working on next-gen a next-gen codec, called Daala (or PatentCake if you prefer):

https://xiph.org/daala/
https://wiki.xiph.org/Daala