Is there a theoretical limit to compression @ fixed quality?

[bur]

At the same bitrate H.264 based codecs generally achieve better video quality than H.263 based ones. The reason why they weren't used before is processing power - or so I think.

So I was wondering if there are experimental or maybe "on paper only" methods that could achieve even better quality at the same bitrate that aren't used yet because they'd need too much CPU power?

Or the other way around, is there are realistic chance that someone will come up with a new way of compressing video that needs only slightly more ressources but way less bitrate?

Maybe there's even a theoretical limit to what bitrate is absolutely needed to result in a given PSNR?


Or put shortly, what's preventing us currently from achieving better results : The knowledge how to do that or the power of standard desktop computers?



Less bitrate for same video quality.

[Keiyakusha]

So I was wondering if there are experimental or maybe "on paper only" methods that could achieve even better quality at the same bitrate that aren't used yet because they'd need too much CPU power?
h265

Maybe there's even a theoretical limit to what bitrate is absolutely needed to result in a given PSNR?
Does someone still cares about PSNR? It represents useless mathematical numbers, not the quality.

what's preventing us currently from achieving better results : The knowledge how to do that or the power of standard desktop computers?
Both.

[iwod]

I read somewhere To achieve another 50% bitrate reduction at the same quality would require 4 times as much processing power. At least that is the aim of H265, it is hard imagining a 720P video with 700Kbps bitrate looks good.

[chainring]

I read somewhere To achieve another 50% bitrate reduction at the same quality would require 4 times as much processing power. At least that is the aim of H265, it is hard imagining a 720P video with 700Kbps bitrate looks good.Somewhere around here is a thread started by Dark Shikari where he got 1080p in ~660Kbps and it looks real good. Mind you, the clip he uploaded (V for Vendetta) was one of the tougher scenes he came across and, IIRC, the thread was from a few years ago.

[nm]

That was 720p encoded with x264 using pretty fast settings. The clip was heavily denoised though:

http://forum.doom9.org/showthread.php?p=1035907#post1035907

[chainring]

That was 720p encoded with x264 using pretty fast settings. The clip was heavily denoised though:

http://forum.doom9.org/showthread.php?p=1035907#post1035907Oops, you're right, it is 720p. Teaches me to assume when I'm using a lower resolution monitor than usual.

Still, 720p in ~660 back then...pretty crazy.

[Ghitulescu]

....

So I was wondering if there are experimental or maybe "on paper only" methods that could achieve even better quality at the same bitrate that aren't used yet because they'd need too much CPU power?

Or the other way around, is there are realistic chance that someone will come up with a new way of compressing video that needs only slightly more ressources but way less bitrate?

Or put shortly, what's preventing us currently from achieving better results : The knowledge how to do that or the power of standard desktop computers?

Both.

Actually the desktop computers are not considered in any standard I am aware of.
Either the codec is asymmetric, which means it requires a much more CPU power at encoding than on decoding (a typical example being MPEG-series), or symmetrical (typical DV/MiniDV and related including HD versions), but in this case the CPU-power was not so intensive.
Secondary, traditionally all video was done on RISC architectures, while the PCs are CISC. HW-accelerators are always RISC, because RISC architectures are much easier to be optimised for speed and to be debugged if needed.

But you have to define quality first, then talk about compression.

[Keiyakusha]

Actually the desktop computers are not considered in any standard I am aware of.


We all understand that by desktop he probably mean hardware, and he said desktop probably because it is most powerful hardware compared to others. If desktop can't handle something, other things are out of question.

Either the codec is asymmetric, which means it requires a much more CPU power at encoding than on decoding (a typical example being MPEG-series), or symmetrical (typical DV/MiniDV and related including HD versions), but in this case the CPU-power was not so intensive.
Currently, for dealing with h265, most advanced 6-cores Core i7 is not enough, or even 2 of them. That's the point. Of course for those who can wait weeks for processing a bunch of frames that's not the case ^__^ Sure this may more or less change in the future.

But you have to define quality first, then talk about compression.
in this thread, quality - something that looks like X with Y final size. Better quality -> something that looks as good as X, but with for example Y/2 final size. Or vice versa.

Usually you're going offtopic way too much so if you want to answer me - use pm please.

[iwod]

That was 720p encoded with x264 using pretty fast settings. The clip was heavily denoised though:

http://forum.doom9.org/showthread.php?p=1035907#post1035907

Wow i never knew how much could be done with x264 denoise and low bitrate.

And that was from YEARS AGO..!!!!

Looks like i have to go back to my room and do more testings....

[benwaggoner]

Well, I don't think we could ever code a single frame in less than 1-bit :)...

Seriously, there's huge room for improvements in video codecs over what we've got today. H.265 has a bunch of interesting stuff. But perceptually optmized preprocessing/postprocessing hasn't seen that much work for a while. HD DVD's H.264 implementation had theoretical support for parameterized grain synthesis, although it wasn't used in real-world projects. But imagine a codec which could heavy denoising on encode and then the decoder could synthesize visually identical noise patterns on playback. That could result in a huge bitrate savings for "difficult" content.

In-loop deblocking could be more adaptive and flexible as well.

Codecs are always designed to hit a certain decoder complexity budget. The more and faster memory and processing the decoders have, the richer the options the decoder can use.

[CruNcher]

Wow i never knew how much could be done with x264 denoise and low bitrate.

And that was from YEARS AGO..!!!!

Looks like i have to go back to my room and do more testings....

Yep today we have 10 bit so the banding would be no issue anymore though also with flashkyu @ playback it should be gone :)
Noise and Film Grain most times take almost 50% of the bitrate and more, though removing only Noise is hard without touching the Grain and this is altering what the director intended in such a way that enthusiasts gonna kill you hence Blu-Rays with DNR lose in every review ;)

HD DVD's H.264 implementation had theoretical support for parameterized grain synthesis, although it wasn't used in real-world projects.

Yeah Thompsons Film Grain Modeling approach looked decent very sad that it never was used and you just see the DXVA support in Hardware _FGM for it but it just sits there for no use ;)

[iwod]

Yep today we have 10 bit so the banding would be no issue anymore though also with flashkyu @ playback it should be gone :)
Noise and Film Grain most times take almost 50% of the bitrate and more, though removing only Noise is hard without touching the Grain and this is altering what the director intended in such a way that enthusiasts gonna kill you hence Blu-Rays with DNR lose in every review ;)

HD DVD's H.264 implementation had theoretical support for parameterized grain synthesis, although it wasn't used in real-world projects.

Yeah Thompsons Film Grain Modeling approach looked decent very sad that it never was used and you just see the DXVA support in Hardware _FGM for it but it just sits there for no use ;)

I just never realized that grain and noise were that big at all. Finally I could understand why WMV and RMVB were good at those low bitrate.

[Ghitulescu]

We all understand that by desktop he probably mean hardware, and he said desktop probably because it is most powerful hardware compared to others. If desktop can't handle something, other things are out of question.
Standalones that could handle H.264 appeared about 2 years before the most powerful Intel-based desktop computer could even play/decode it. Even now, the powerful i7 CPU needs the aid of a GPU to decode/encode H.264 in real-time or a little bit better. A tiny HD-camcorder could do this without the need for 90W and a huge fan.
It happened the same before, eg with MPEG-2 and MPEG-1, and M-JPEG and many other codecs.
Usually you're going offtopic way too much so if you want to answer me - use pm please.
Because the joint group for establishing new codecs don't care about desktop PCs could make my statement off-topic, I have to agree. The desktop computational power plays however no role in the new H.265, nor the desktops are the target of the new format/codec. People that provide the videos generally use hardware encoders, the software ones are used more or less by small enterprises or content distributors (eg Criterion).

While the RISC processing power is a decisive factor, the key ones are the bandwidth required and the efficiency of encoding of higher framesizes (HDTV and beyond) to fit the bandwidth. The rest are just regular requirements or marketing clauses.

I chose H.265 as an example, because H.265 is one project that has some public documents available and anyone can have a look, if interested in.

To answer the question, none. There are algorithms that could provide better compressibility, and there are RISC processors that could implement them.
If however the OP restricted the vision to the smaller world of destop PCs, well, yes, the CPU power is definitively the handbrake to implement these codecs/algorithms on PCs - but this won't prevent HD-camcorders, HDTV-SAT-Receivers, HD-TV-sets, mobile HD-players from using the next generation of codecs, from the next day the corresponding standard be approved.

[Keiyakusha]

Even now, the powerful i7 CPU needs the aid of a GPU to decode/encode H.264 in real-time or a little bit better. A tiny HD-camcorder could do this without the need for 90W and a huge fan.

That's not true. What is used in camcoders is a way simplified version of the h264. And any CPU starting from Core2Quad can decode even most complex h264 stream, let alone core i-series.

Because the joint group for establishing new codecs don't care about desktop PCs could make my statement off-topic, I have to agree. The desktop computational power plays however no role in the new H.265, nor the desktops are the target of the new format/codec.
Your statement is offtopic not because of what h265 authors care or don't care about, but because you underestimating the power of the CPUs and don't want to accept my explanation why I continued to compare performance against CPU and not some other hardware. Also this is pretty much your habit to fill threads with lots of information that on 90% consists of water.

To answer the question, none.
Everything was answered even before your 1st post in this thread. I don't want to continue this discussion so stop quoting me. Bye.

[hello_hello]

Standalones that could handle H.264 appeared about 2 years before the most powerful Intel-based desktop computer could even play/decode it. Even now, the powerful i7 CPU needs the aid of a GPU to decode/encode H.264 in real-time or a little bit better. A tiny HD-camcorder could do this without the need for 90W and a huge fan.
It happened the same before, eg with MPEG-2 and MPEG-1, and M-JPEG and many other codecs.

I used to watch h264 video with my Pentium 4 PC. Not full HD admittedly, as it didn't have enough grunt, but I used my PC to decode h264 long before I saw a standalone that could handle it.
Maybe you should try using your PC to decode video before making any more outrageous claims. My old dual core E6750 decodes full HD video in real time without any problem. Just to see how easily it does it, I switched decoding to the CPU and opened a 1080p h264 video. CPU usage hovered around 30%, which also includes the decoding of 5.1ch AAC audio.
Which Intel CPUs were too slow to play mpeg1 or mpeg2 video? How far back do you have to go?


If however the OP restricted the vision to the smaller world of destop PCs, well, yes, the CPU power is definitively the handbrake to implement these codecs/algorithms on PCs - but this won't prevent HD-camcorders, HDTV-SAT-Receivers, HD-TV-sets, mobile HD-players from using the next generation of codecs, from the next day the corresponding standard be approved.

I guess it'll also prevent video cards from being designed to decode h265, just like they do now with h264? Or maybe it'll prevent some other sort of hardware decoding/encoding from being implemented? If not, I guess the CPU will continue to be fairly irrelevant for decoding at least... just as it is today.

[amtm]

Which Intel CPUs were too slow to play mpeg1 or mpeg2 video? How far back do you have to go?

I remember having issues with stuttering DVDs without an MPEG2 decoder card back in 98 but that was when I still had a 66 Mhz Pentium. So we are talking about a 5 year old CPU by that point and thus having to go pretty far back to find an example. The next year when I upgraded to a PII 400mhz there was no problem.

[Ghitulescu]

Yeah, decoding using an asymmetric codec :)

In computer industry things are changing rapidly, more rapidly than in other, so people tend to forget things. They tend to forget that reencoding a DVD9 into a DVD5 was needed to be performed overnight in the earliest days, like todays BDRs, by the power of the CPU only.

They also forget that people that intended to play DVDs on their computer at the beginning of the DVD-playback on PCs needed an MPEG-2 HW kit, one of the most known being the Hollywood+ card (discontinued AFAIK in 2001).

The DVD specs were laid out in 1996. In 1996 most existent PCs couldn't even encode a CD to MP3 in real-time. Was the industry so stupid, to promote a standard that could have been possible to implement only 4-5 years later? Had the industry hazardously bet on the Murphy's law? No, they already had the computational power and the algorithm and they designed the medium too - just that this wasn't the PC. The standalone DVDplayers (which appeared some 2 years later) could play DVDs at least 2 years before the PC at a fraction of its electricity needs. The very first authoring suites for computers (including here the SGI) had HW-encoders. Also the capture cards had to have HW-encoders on-board not to stress the earlier PC too much. Only later it was possible to translate the MPEG's specs into CISC instructions (Intel, AMD etc.) for that SW codecs and encoders/decoders to be possible. And as I said, even then it was not always possible to have a real-time solution purely in software.

So, if they draft nowadays the specs for H.265, they already have both the algorithm (50% compression vs. the "old" H.264) and the computational power. The PC must wait. As usual.

[hello_hello]

In computer industry things are changing rapidly, more rapidly than in other, so people tend to forget things. They tend to forget that reencoding a DVD9 into a DVD5 was needed to be performed overnight in the earliest days, like todays BDRs, by the power of the CPU only.

"Not exaggerating" isn't the same thing as forgetting.
Re-encoding DVD9 to DVD5.... I guess it doesn't matter if it takes the PC an hour or a week, it's the PC 99.99% of people use for the job. In those early days, were there standalone players readily available for re-encoding DVD9 to DVD5, or were you trying to make a different point I'm not seeing?

Was the industry so stupid, to promote a standard that could have been possible to implement only 4-5 years later? Had the industry hazardously bet on the Murphy's law? No, they already had the computational power and the algorithm and they designed the medium too - just that this wasn't the PC.

Even if in the early days of MP3 most PC's couldn't encode an MP3 in real time, they could still play them just like standalone players. Unlike most standalone players though, they could also encode MP3s, even if not in real time, so what exactly is your point?
Back in 1996, where do you think most people were getting their MP3s? Were they converted from CDs using a PC (in less than real time), was everyone buying dedicated standalone MP3 encoders, or were MP3s appearing out of thin air?

The standalone DVDplayers (which appeared some 2 years later) could play DVDs at least 2 years before the PC at a fraction of its electricity needs.
The very first authoring suites for computers (including here the SGI) had HW-encoders. Also the capture cards had to have HW-encoders on-board not to stress the earlier PC too much.

By the time standalone DVD players were released, a current PC had a plenty fast enough CPU to decode them. There's been third party DVD decoding software since the beginning. Yes the PC uses more electricity. So? DVD players were also very expensive in the early days.
Today though we use the graphics card for decoding h264 video. Did you miss my question about adding a hardware h265 encoder/decoder to the PC or are you unnecessarily fixated on the CPU for some inexplicable reason? There's nothing about adding a dedicated hardware encoder/decoder to a PC that makes the PC less PC-like. I don't know why you keep mentioning hardware encoders like they're something evil.

So, if they draft nowadays the specs for H.265, they already have both the algorithm (50% compression vs. the "old" H.264) and the computational power. The PC must wait. As usual.

LOL! Well I guess you won't be playing h265 in any of your current standalone players? Waiting for new PC hardware or waiting to buy a new standalone player?.... Yep, the PC's at a real disadvantage there.....

[Ghitulescu]

There were several points, which could be missed only by bad faith or purposely blindness:
- decoding can only occur after encoding. Asymmetric codecs require a much more computational power to encode than to decode - this allows relatively weak players to decode the content, while powerful HW encoders were needed to encode the content. This shifts also the burden of price from the consumer (as no need to pay for the super GPU in the player, like he has for a graphic card in a computer) to the content producer, which also needed only one time [expensive] acquisition. That means, for computers, that a weaker HW is needed for a PC to decode than to encode. Everything said before conveniently considered only the decoding part and gently "blurred" some temporal borders.
- I don't remember the synchronizing between the first DVDplayers and the first DVD-ROMs ;) I remember instead 1-1.5 years difference (late 1997-early 1998 vs early 1999), I also remember that the first DVDrips were performed with a standalone and a capture card. And I also remember that most computers existent couldn't play the DVDs, without the aid of a HW card (sold as a kit).
- the industry doesn't care about the people, one can spend 12 months to reencode a movie on his computer for what they care. But they should be able to encode in real-time or faster, because otherwise all [smart-]guys would only idle, as no content would have been available for them to "back-up" (eg all Digital-TV and SAT-TV are done in real-time or faster, and they do care about this).
- there are no H.265 HW nor SW, as no H.265 specs are available, rumours are that the first draft will appear next year in February. I would count aloud the months/years until the first HW H.265-solution for PC will be ready.

Yes, they probably have now all the pieces for the new format. Only the details and, probably, the last subjective tests are to be set, before the first draft.

And finally, to further clarify the matter, the lag between the DVD specs and the first generation of DVD players was due to manufacturing delays (for chips, players and media) and not because they have wait for the HW to "grow up" to the specs. In fact, they had a sort of bad surprise to notice that the HW improved since the laid out of the draft (see the CSS issue).

[hello_hello]

There's no bad faith or purposeful blindness, I just can't see what point you're trying to make aside from stating the obvious.

There's no law which says you "should" be able to encode anything in real time or faster, in fact as each new digital standard became popular chances are you needed the latest PC to encode it at a reasonable pace. Mpeg2, MP3, DivX, h264.... they were all the same. I didn't bother backing up DVDs in the early days partly because it took so long, but mainly because while my PC was doing it, it was basically unusable for anything else. Likewise I didn't start converting to Xvid until I had a faster PC, then I stuck with Xvid encoding longer than I ideally would have liked to because the PC I had at the time was painfully slow encoding x264. Will h265 be any different? Undoubtedly not. Chances are by the time h265 becomes mainstream the fastest CPUs might be able to encode it at a snail's pace. So once again it's either wait for CPU power to catch up or buy a hardware encoder. Nothing's changed. Nothing's new. My PC can encode x264. It'll be able to encode x265, even if very slowly. Your standalone player can't no matter how rigidly it conforms to "standards", no matter what processor it uses for decoding, and it'll never be able to no matter how long you wait.

[Ghitulescu]

There's no bad faith or purposeful blindness, I just can't see what point you're trying to make aside from stating the obvious.
The point was an answer to the original question:
So I was wondering if there are experimental or maybe "on paper only" methods that could achieve even better quality at the same bitrate that aren't used yet because they'd need too much CPU power?

Or put shortly, what's preventing us currently from achieving better results : The knowledge how to do that or the power of standard desktop computers?
which was answered:
Both.
which is wrong, there is the algorithm and the processing power. It is highly probable that not on a desktop PC, but on a specialised chip. Probably the SW solution will lack the power to encode H.265 on the current PCs, so people hoping to "backup" BD50 in the size of a DVDrip with no quality loss will have to wait a bit :).

There's no law which says you "should" be able to encode anything in real time or faster, in fact as each new digital standard became popular chances are you needed the latest PC to encode it at a reasonable pace. Mpeg2, MP3, DivX, h264.... they were all the same. I didn't bother backing up DVDs in the early days partly because it took so long, but mainly because while my PC was doing it, it was basically unusable for anything else. Likewise I didn't start converting to Xvid until I had a faster PC, then I stuck with Xvid encoding longer than I ideally would have liked to because the PC I had at the time was painfully slow encoding x264. Will h265 be any different? Undoubtedly not. Chances are by the time h265 becomes mainstream the fastest CPUs might be able to encode it at a snail's pace. So once again it's either wait for CPU power to catch up or buy a hardware encoder. Nothing's changed. Nothing's new. My PC can encode x264. It'll be able to encode x265, even if very slowly. Your standalone player can't no matter how rigidly it conforms to "standards", no matter what processor it uses for decoding, and it'll never be able to no matter how long you wait.

I really, really, have nothing to comment without going way off-topic :) other than a player cannot encode, as this is the job of a recorder.

[Keiyakusha]

which is wrong, there is the algorithm and the processing power. It is highly probable that not on a desktop PC, but on a specialised chip. Probably the SW solution will lack the power to encode H.265 on the current PCs, so people hoping to "backup" BD50 in the size of a DVDrip with no quality loss will have to wait a bit :).

Which is right.
There is no algorithms that will be able to achieve big improvements in compression without multiplying power needed to process the result (decoding too). Which is equal -to "there is no knowledge"
There are algorithms that is capable to achieve more or less big improvement in compression by using "brute force", but currently they are not used because nothing can handle them. So both possible reasons mentioned by Bur are correct. It is your problems if you don't want to accept that. Blurays for example not taking advantage of the full h264 potential. But it is possible to take full advantage on PC. I really doubt something will take the advantage of those "brute force" algorithms in h265, except PC.

Can you please stop this show? I understand that you want to look like a smart one, but you overdoing it.

[benwaggoner]

There is no algorithms that will be able to achieve big improvements in compression without multiplying power needed to process the result (decoding too). Which is equal -to "there is no knowledge"
There are algorithms that is capable to achieve more or less big improvement in compression by using "brute force", but currently they are not used because nothing can handle them.
Actually, one of the initial goals of H.265 is to offer a mode that offers 25% better compression efficiency than H.264 at 50% the CPU decode required.

"Power" is also a pretty vague term. There's memory bandwidth and memory available for reference frames, there's easily SIMD/DSP'd functions that can be done in paralell, and there's serialized stuff like more advanced entropy coding modes.

A lot of what H.265 adds seems more about having a lot more flexibility to reference previous frames and already-coded parts of the same frame. That's stuff that a modern PC should be able to do without breaking a sweat; it's embedded devices where an extra $1 of COGS is a dealbreaker where that might be a concern.

Blurays for example not taking advantage of the full h264 potential. But it is possible to take full advantage on PC. I really doubt something will take the advantage of those "brute force" algorithms in h265, except PC.
IIRC, it was actually Intel who demanded the 4-slice requirement for Level 4.1 in Blu-ray, so they could paralleize decode more easily in software decoders.

I'm not sure if you're talking about encode or decode for "Brute Force" - generally that's something we talk about for encoding, and doesn't apply to decoding.

One of the most exciting things in compression over this last decade is seeing how close fast heustic methods can get to brute force quality in a tiny portion of the time that a true brute force algorithm requries.

But as we've seen in all standardized codecs, we get big improvements in compression quality over time as new techinques are applied, but decoder complexity for the same Profile@Level remains relatively constant even as video looks better and uses those more advanced techniques.

[benwaggoner]

I just never realized that grain and noise were that big at all. Finally I could understand why WMV and RMVB were good at those low bitrate.
WMV never did any kind of grain synthesis. I don't recall RealVideo doing it either, but it's been a long time.

The codec I remember most aggressively doing post-processing and grain/noise synthesis was VP6. It was quite effective in practice at hiding artifacts and lack of detail preservation.

[CruNcher]

WMV never did any kind of grain synthesis. I don't recall RealVideo doing it either, but it's been a long time.

The codec I remember most aggressively doing post-processing and grain/noise synthesis was VP6. It was quite effective in practice at hiding artifacts and lack of detail preservation.

Don't forget DivX Networks who where in the situation to crawl on their knees if they wouldn't do something when H.264 arrived ;) and the short time escape was the introduction of the @ first default Sharpen Post Pro + Film Mode when needed @ the Decoding stage ;)

[Dark Shikari]

Actually, one of the initial goals of H.265 is to offer a mode that offers 25% better compression efficiency than H.264 at 50% the CPU decode required.This was some number that someone made up before even the first proposals were submitted. Nothing in current development comes even close to looking like that.

A lot of what H.265 adds seems more about having a lot more flexibility to reference previous frames and already-coded parts of the same frame. That's stuff that a modern PC should be able to do without breaking a sweat; it's embedded devices where an extra $1 of COGS is a dealbreaker where that might be a concern.

A 12-tap interpolation filter, 12th-pel motion compensation with custom coefficients, transform sizes up to 64x64 filled with multiplications, and yet another added loopfilter don't sound much like "without breaking a sweat".

[*.mp4 guy]

A 12-tap interpolation filter, 12th-pel motion compensation with custom coefficients, transform sizes up to 64x64 filled with multiplications, and yet another added loopfilter don't sound much like "without breaking a sweat".

AFAIK most of the proposals for "large transforms" just use use 8*8 dct analogs and downsampling, IE downsample by 8 -> transform -> (other stuff) -> inverse transform -> upsample.

Also, the interpolation filters might actually be worse (performance wise) then 12 taps would imply, some of the proposals are for directional (non separable) non-linear filters. Though I doubt that these filters will see use considering how half-assed many of the "large transform" proposals are.

[Ghitulescu]

This was some number that someone made up before even the first proposals were submitted. Nothing in current development comes even close to looking like that.

The publicly available documents (at least those I've seen) stated 50% compression-ratio of the H.264 at similar visual quality.

Any standard comes from a proposal and tries to solve an objective technical problem - in this case, they said they want to deliver HD content (2k and beyond) without the need to increase the decoding requirements (like those existent or available in the near future in tablets and other mobile devices, which are specifically one target of this future standard).

MPEG-2 started the same way, with similar proposals (better than MPEG-1 and suitable for higher framesizes than eg VCD, ie DVD/DVB). So did H.264 (targeted at HDTV). First one sets the target, then the implementation details. If the first draft is to be made public in Feb.2012, ie in 3 months that includes the "dead" winter holidays, then the algorithm and the prototypes have been already set and undergo preliminary tests. Probably the specs will be changed on the fly, but nevertheless the main requirements (videoformat, bandwidth and GPU power) will be fulfilled.

[hello_hello]

It's interesting to see even our resident x264 developer can benefit from a history lesson on the development of mpeg encoders followed by a quick reading of the tarot cards. :)

[CruNcher]

Though i wonder more how long will it take for a ISV to make a practical encoder (adding the knowledge they got from tuning H.264) that can beat x264 looking in the past it always took a while especially if you calculate how many fine tuning time actually flow into x264 by so many individuals :)
It wouldn't surprise me if first implementations suck visually even with the calculated efficiency they should provide see Dark Shikaris first BBC Samsung test, i remember when XviD blowed x264 still away for a long time in most practical low bitrate visual tests and also times where Ateme visually beat x264 which changed rapidly when Loren,Dark and later masternobody showed up, the good thing that knowledge is all here now and doesn't have to be reinvented i hope ;)

[benwaggoner]

This was some number that someone made up before even the first proposals were submitted. Nothing in current development comes even close to looking like that.
Sure. I was adding context to what was said above about the initial goals of H.265.

I sure would love if they figure out how to do that, though :).


A 12-tap interpolation filter, 12th-pel motion compensation with custom coefficients, transform sizes up to 64x64 filled with multiplications, and yet another added loopfilter don't sound much like "without breaking a sweat".
Yeah, there's lots of CPU expensive stuff in H.265, but not all of the new quality-improving features are MIPS intensive. Some are more memory working set or memory bandwidth intensive. So it's possible we could see significant quality improvements versus H.264 on today's PC hardware, which generally aren't memory bound for video decoding.

[ckmox]

just a noob passing by i want to ask will H265 be in 10-bit or still 8-bit?

and is their still some major room for improvement on x264 to make somewhat comparable (compression wise) to h265 when the time comes?

EDIT:

x264 is base on h264 that is a standard and that h264 standard is somewhat a hindrance too since you cannot put new radical algorithms that developers learn from years of programming x264 for example, so i wonder if x264 developers like akupenguin, dark shikari, etc can gather what they learn from x264 and make a brand new codec that is open source and superior to x264, since im observing that x86 will be going into mobile phones too in the near future so we can just download a x86 media player like VLC to play this new codec

ye i know i can always dream lol

[smegolas]

x264 is base on h264 that is a standard and that h264 standard is somewhat a hindrance too since you cannot put new radical algorithms that developers learn from years of programming x264 for example, so i wonder if x264 developers like akupenguin, dark shikari, etc can gather what they learn from x264 and make a brand new codec that is open source and superior to x264, since im observing that x86 will be going into mobile phones too in the near future so we can just download a x86 media player like VLC to play this new codec

ye i know i can always dream lol

Except the widespread adoption of H264 was helped by cheap hardware players, console support, iDevice support, etc The popularity of Bluray has increased demand and pushed prices down for h264 chipsets. Many TVs have built in support because digital terrestrial broadcasts in UK and Europe are H264 HP@L4.1...I don't know about America..

All these things helped to make it popular and helped to push prices of hardware down. So it is impossible for someone to just make up their own codec and hope that it will be widely adopted.

On a related note I worry about HEVC because it will come out after the next generation of consoles, so they will probably not support it. Apple won't want to adopt it because they don't like breaking compatibility with older devices (their iTunes stuff is Main Profile without CABAC afaik). There is no new Bluray format that will help make hardware decoders cheap.

[sneaker_ger]

just a noob passing by i want to ask will H265 be in 10-bit or still 8-bit?

From what I've read most proposals suggested increased precision over H.264, so I presume it will offer at the very least 10 bit, most likely even more (up to 16 bit?). And I doubt it will be for professional use only, like in H.264, which also offers higher bitdepth, but in the consumer world only 8 bit is widespread.

Except the widespread adoption of H264 was helped by cheap hardware players, console support, iDevice support, etc The popularity of Bluray has increased demand and pushed prices down for h264 chipsets. Many TVs have built in support because digital terrestrial broadcasts in UK and Europe are H264 HP@L4.1...I don't know about America..

All these things helped to make it popular and helped to push prices of hardware down. So it is impossible for someone to just make up their own codec and hope that it will be widely adopted.

On a related note I worry about HEVC because it will come out after the next generation of consoles, so they will probably not support it. Apple won't want to adopt it because they don't like breaking compatibility with older devices (their iTunes stuff is Main Profile without CABAC afaik). There is no new Bluray format that will help make hardware decoders cheap.

I agree, we will need some applications for it. Many broadcasts are still in mpeg-2 (even HD in e.g. Japan and the US) and a Blu-Ray successor is not around the corner. Maybe when UHDTV comes...

But processing power is of course a limit. If HEVC is similar to H.264, just with more features thrown at it to reach the 50% increased compression goal, that might be a problem. Broadcasts and webstreams (like youtube) are far from fully utilizing H.264's full power. Everyone here on doom9 knows what encoders like x264 are capable of, and that is definitely not what we see in broadcasts and streaming.