x265 - Work already started?

[mandarinka]

That USAC thing looks like a competitor to Opus, it doesn't seem to be a broad general-purpose format like aac (or vorbis).

[IgorC]

There is no such thing as standard with not broad general-purpose. And USAC is a new standard like AAC, H.264 etc.
USAC isn't competitor to Opus. Opus is a low delay codec for real time applicactions (though it's also suitable for archiving). USAC has a very high delay.

So it's to expect to see H.265+USAC as current H.264+AAC in future.

[shon3i]

So it's to expect to see H.265+USAC as current H.264+AAC in future. Well we didn't see much H264+AAC combinations instead of that we see much more H264+DTS/AC3/FLAC/Other Lossless. AAC is practically skipped for most common use. I don't think that USAC will be more popular

[nm]

Well we didn't see much H264+AAC combinations instead of that we see much more H264+DTS/AC3/FLAC/Other Lossless. AAC is practically skipped for most common use. I don't think that USAC will be more popular
Huh? AAC is almost always used with H.264 in online streaming applications, which is a huge market these days. USAC will be suitable for exactly that use too, but not as an alternative for DTS and lossless formats.

[shon3i]

Only if USAC became hybrid format like DTS-HDMA or TrueHD, and used from start in next optical disc specifications, btw why will not replace crappy DTS, any codec will allready replace DTS including AC3 in terms of quality if we look at lastest EBU testing of multichannel codecs.

[nm]

btw why will not replace crappy DTS, any codec will allready replace DTS including AC3 in terms of quality if we look at lastest EBU testing of multichannel codecs.

Can you link to the latest test? In the 2007 test DTS 1500, DD+ 448 and WMA9 448 were the only codecs that came close to transparent reproduction, and DTS was actually used in some tests as a "transcoding codec" to play HE-AAC streams on standard AV equipment. Granted, DTS also had 5 times more bits to spend than most of the competition. :)

My point was just that USAC is not targeted (nor marketed) for lossless/nearly lossless encoding, so it will probably end up used at lower bitrates.

[CruNcher]

Only if USAC became hybrid format like DTS-HDMA or TrueHD, and used from start in next optical disc specifications, btw why will not replace crappy DTS, any codec will allready replace DTS including AC3 in terms of quality if we look at lastest EBU testing of multichannel codecs.

Next Optical Disc Format ? what should that be it's pretty clear Blu-Ray was the last one. We might see a holographical format but if that comes in Disc form isn't really clear. But im pretty sure Consumer @ least wont see any new Disc Format anymore, Blu-Ray will be their last one, that era is over.

[hajj_3]

USAC is great at low bitrates, and equal at normal audio bitrates to existing codecs so it looks as though the target for this technology would be phones and digital radio where a low bitrate is sought after. Its a shame there is an increased delay over other technologies though. We don't need any new audio codecs, dolby digital plus and dts-hd ma is good enough for anyone.

As for optical disc formats that is difficult to say, think there probably will be optical disc formats in the future as memory cards cost alot more and even with 100mb broadband downloading bluray quality will still take qute a while, it will be 10yrs or so until 100mb is common place worldwide.

[mandarinka]

Well, at say 128kbps for stereo 44khz 16bit, its advantage won't be that big, over LC AAC (I think so after reading the thread on HA forum). In which case I'd say it's better to use the tried and true encoders with tuned psychoacoustic models, instead of the new stuff, which will be less tested and mature.

(Edit, actually, this is rather off-topic here, so we stop with this unless the comments are moved to audio section or something.)

[IgorC]

Well, at say 128kbps for stereo 44khz 16bit, its advantage won't be that big, over LC AAC (I think so after reading the thread on HA forum). In which case I'd say it's better to use the tried and true encoders with tuned psychoacoustic models, instead of the new stuff, which will be less tested and mature.

USAC is a superset of AAC. It's AAC with some new tools (not counting AMR-WB+ in very low bitrate range) . So transition will be easy.
USAC will be especially good for movietracks as it has AMR-WB+ (speech coder) and much improved MPEG Surround stereo at low bitrates. You wouldn't beleive how high quality is at only 40 kbps on movietracks.



Edit, actually, this is rather off-topic here,
It's relevant to H.265 (audio part, container etc.)

[mandarinka]

While it's not clear how soon is h.265 going to matter, can anyone throw an educated guess as to what kind of cpu performance is going to be needed to decode in software (lets assume a BDrip: 1920x1080, 24fps, up to 20Mbps, all the encoding tools in use)?

For example with sandy bridge arch, an HT-enabled dualcore (i3 2100)? Or an entry quad (i5 2300-2400)?
Since the format will likely have a slower start, it probably isn't important what the performance of the initial decoders is going to be, let's think about a reasonably SIMD-optimised implementation.

[iwod]

While it's not clear how soon is h.265 going to matter, can anyone throw an educated guess as to what kind of cpu performance is going to be needed to decode in software (lets assume a BDrip: 1920x1080, 24fps, up to 20Mbps, all the encoding tools in use)?

For example with sandy bridge arch, an HT-enabled dualcore (i3 2100)? Or an entry quad (i5 2300-2400)?
Since the format will likely have a slower start, it probably isn't important what the performance of the initial decoders is going to be, let's think about a reasonably SIMD-optimised implementation.

Well unlike all previous Video Codec, Hardware Decoder is now widely available from Desktop to Smartphone CPU. As long as those are well planned ahead you could have a H.265 Decoder in your CPU before it even gets popular.

Back to your questions, some paper i read said it would require 4 times the processing power to software decode....

[mandarinka]

That's true, but if you look at the history of h.264 hw decoding, it was plagued for many years by limited compatibility, software support (first the decoders were only proprietary, only dxva, could only connect to renderer, later they couldn't handle the maximum number of reference frames...). I'd say gpu decoders only became sort of hassle free with coreavc 2.0's "cuda" (1.x couldn't do 16 reference frames) and vdpau (non-windows). If one was really picky about convenience of the decoding, one could say that we had to wait for lavcuvid (2011) and lav video's dxva (2012). Let's not forget about hw bugs too (1024 or 1888 width resolutions broken with some nvidia cards...)
And meantime, 10-bit profile appeared...

So when going to buy a PC in the near future, it's not that unreasonable to think about HEVC when picking a cpu. Well, unless you plan to ditch it in 2 years or less anyway, of course :)

[IgorC]

http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
The preliminary requirements for NGVC were bit rate reduction of 50% at the same subjective image quality comparing to H.264/MPEG-4 AVC High profile, with computational complexity ranging from 1/2 to 3 times that of the High profile. NGVC would be able to provide 25% bit rate reduction along with 50% reduction in complexity at the same perceived video quality as the High profile, or to provide greater bit rate reduction with somewhat higher complexity

Chipmakers are preparing for HEVC already now
http://www.ziilabs.com/products/processors/zms40.aspx

[mandarinka]

Hmm, according to the site, they are using some sort of programmable DSP units (for their webm support), so the HEVC listed amongst the capabilites is probably more of a promise to eventually update the firmware to handle it. They don't specify the resolutions/bitrates/profiles/levels...

[Atak_Snajpera]

does hevc have film grain modeling? h.264 has it but it is not used at all for some unknown reason.

[shon3i]

IIRC FGM is something like SBR in AAC audio, and if i remeber correctly only ateme in beta has it. I think they are quit because decoder need to support FGM decoding and should use magic to recontstruct fine grain. They probably not find good spot.

[Atak_Snajpera]

fgm should be mandatory in decoder like deblocking filter then.

[Atak_Snajpera]

also mandatory "in-loop" deband filter in hevc decoder would be nice. i hate that currently after denoising i have to manually enable postprocess filter in ffdshow in order hide ugly artifacts. even higher bitrate does not help.

[mandarinka]

That's probably better served with increased internal bitdepth, similar to high 10 profile encoding with x264. Actual debanding could be quite destructive for dark/low-contrast detail, if gradfun* filters are any indication.

[Bloax]

Wouldn't that be solved by having, like - a --no-deband switch?

[shon3i]

That's probably better served with increased internal bitdepth, similar to high 10 profile encoding with x264. Actual debanding could be quite destructive for dark/low-contrast detail, if gradfun* filters are any indication.
Exactly, if h265 bring us 10=> bitdepth, higher fps/resolution form start with better compression ratio, that will be good point switch from h264

[Atak_Snajpera]

Here is example how useful is deband in ffdshow
CRF20 with default x264 settings
without deband filter
http://img688.imageshack.us/img688/9914/nodeband.png

with deband filter
http://img190.imageshack.us/img190/8137/deband.png

[benwaggoner]

I wonder if H.265 could he an inflection point to introduce broad decoder support for scalable video coding. H.264 SVC never got past chicken/egg. But as long as a new decoder is being made...

[spawnbsd]

I would be happier to see 10bit made mandatory in HEVC High Profile, I'm still not sold on SVC ;-).

[Dark Shikari]

Here is example how useful is deband in ffdshow
CRF20 with default x264 settings
without deband filter
http://img688.imageshack.us/img688/9914/nodeband.png

with deband filter
http://img190.imageshack.us/img190/8137/deband.pngDebanding is a hack to compensate for insufficient internal precision; just use 10-bit instead.

[IgorC]

Here is example how useful is deband in ffdshow
CRF20 with default x264 settings
without deband filter
http://img688.imageshack.us/img688/9914/nodeband.png

with deband filter
http://img190.imageshack.us/img190/8137/deband.png
Can You provide an uncompressed frame for complete judgement of quality?
Probably [de]banding impact will be better to evaluate during playback.

The filter removes banding though at cost of still noticeable blur and detail loss.

[Atak_Snajpera]

ORIGINAL VC-1 ~24 Mbps
http://img714.imageshack.us/img714/9528/originalcr.png

WITH DEBAND x264 CRF20 default settings plus ffdshow deband filter (default settings 1.2 / 16)
http://img408.imageshack.us/img408/8137/deband.png

WITHOUT DEBAND as above
http://img856.imageshack.us/img856/9914/nodeband.png

UPDATE:
x264 10bit CRF20 default settings
http://img190.imageshack.us/img190/1629/nodeband10bit.png



The filter removes banding though at cost of still noticeable blur and detail loss.
You must be a super human to notice that tiny loss during normal view (24fps) but you don't have to be a super human to notice that dancing artefacts on the wall (or in any dark areas)

[LoRd_MuldeR]

Which doesn't change the fact, that these artifacts would probably never have occurred with a proper 10-Bit (or even higher) encode.

Of course given that there was no banding problem in the original source.

You can still apply a "Deband" filter, if your original source contains banding. But only a proper 10-Bit encode would be able to preserve the dither.

[mandarinka]

Quite often though, the banding is appearing for two reasons: 1) it is actually part of the source 2) smoothing prefilters applied by user, especially stuff like fft3dfilter.

I don't think a video format should be made responsible for salvaging either of those cases, especially if it comes with a hit to picture quality and impaired ability to reach transparency.

[Atak_Snajpera]

Which doesn't change the fact, that these artifacts would probably never have occurred with a proper 10-Bit (or even higher) encode.
will it require higher bitrate ? will HEVC support 10 bit+ by default? Or this is gonna be again part of HIGHER PROFILE?

[LoRd_MuldeR]

will it require higher bitrate ? will HEVC support 10 bit+ by default? Or this is gonna be again part of HIGHER PROFILE?

Nope. Higher bit-depth does not necessarily imply a higher bit-rate.

In fact, with higher internal precision (bit-depth) you can achieve a higher compression efficiency and thus might be able to get away with a lower bit-rate for the same level of quality. Even for 8-Bit sources.

Using "only" 8-Bit internal precision primarily is a speed hack. If at all, the speed may be the problem, why they not use a higher bit-depth by default. But if they make a new format, we will need new h/w decoders anyway. So they might choose a higher bit-depth right from the start ;)

[IgorC]

HEVC will have a higher internal bit depth http://www.h265.net/2010/11/analysis-of-coding-tools-in-hevc-test-model-hm-overview.html

[Atak_Snajpera]

I've added 10 bit screenshot for comparison
http://forum.doom9.org/showthread.php?p=1560604#post1560604

8bit + deband filter looks like 10bit for me :)

[chenm001]

Oh, so many people concern HEVC.
My project THEVC is a simple(or call baseline) software model, I drop many of features, it is let us easy to read.
The x265 is opensource and powerful implement.

I am looking for a new job since last year, so I am have a little time, but I am still working on it.
I hope that I can release a IDR only version before Apr 2012, then I will doing a new plan, use GPU speedup or working on P-Slice?

In my plan for the IDR only version, the LCU 64x64, Transform 32x32, IntraPred, Cabac implement in the first version, and QuadTree split, SAO implement late, the deblock and ALF maybe drop in this year, because them have lower compress performance.

btw:
The project status I will update on x265 project homepage every month.
Any ideas can send to my email at 163.com.

[dansrfe]

Is there a current H.264 encoder that can leverage the GPUs via CUDA or OpenCL as well as the CPUs in a customized way? I'm very interested in something like that.

[manma]

Is there a current H.264 encoder that can leverage the GPUs via CUDA or OpenCL as well as the CPUs in a customized way? I'm very interested in something like that.

From what I can gather, hardware vendor specific APIs like DXVA and CUVID are too limited, and rewriting x264 to use things like OpenCL is too difficult/time consuming/not worth the payoff. One thing that I can say for sure though is that there's no real technical limitation. Time is the real issue.

[chenm001]

From what I can gather, hardware vendor specific APIs like DXVA and CUVID are too limited, and rewriting x264 to use things like OpenCL is too difficult/time consuming/not worth the payoff. One thing that I can say for sure though is that there's no real technical limitation. Time is the real issue.

I agree with you.
There is not technical difficulty, the only one is time.
The codec architecture must suit to GPU, but we need many time to experiment.

[chenm001]

I have been upload source yesterday.

[Amdh]

I have been upload source yesterday.

I've just noticed that, thanks for your efforts.
Could you please compile a version for use in CLI mode ?

[chenm001]

I've just noticed that, thanks for your efforts.
Could you please compile a version for use in CLI mode ?

OK, I have been upload a command line execure, it running on Windows.

[Amdh]

OK, I have been upload a command line execure, it running on Windows.

Thanks, I really appreciate it :)

[uneedme]

how did it work?

which input file format could be accepted?......

[chenm001]

how did it work?

which input file format could be accepted?......

It is accept YUV420 only, I am plan integrate into libavcodec when I have the time, so you can use any input late.

[LigH]

For the german readers, the c't magazine issue 14/2012 explains H.265 a bit more detailed.

[IgorC]

http://multimediacommunication.blogspot.com.ar/2012/06/mpeg-news-report-from-100th-meeting.html


N12475 is the Report on preliminary subjective testing of HEVC compression capability which can be found here. It shows impressive results as reported elsewhere, e.g., here. In particular, > 50% bitrate reduction, 67% in class B (HDTV), 49% in class C (WVGA) => mission accomplished!

https://dl.dropbox.com/u/1346434/w12475.zip

[Dust Signs]

For the german readers, the c't magazine issue 14/2012 explains H.265 a bit more detailed.
I saw this on the cover and bought it and I must say that it contains a lot of (new) information (at least for me). Unfortunately, nearly all of the special vocabulary (i.e. words like intra prediction) have been translated to German which makes the article very hard to read. It is still quite a good summary, though.

Best regards
Dust Signs

[LoRd_MuldeR]

In the latest issue of c't magazine somebody complained that the "Main" profile of HEVC won't support higher bit-depths than 8-Bit.

They replied that the SAO (Sample Adaptive Offset) feature will practically eliminate banding, even at 8-Bit. I wonder if this really holds up in reality :confused:

[spawnbsd]

In the latest issue of c't magazine somebody complained that the "Main" profile of HEVC won't support higher bit-depths than 8-Bit.

They replied that the SAO (Sample Adaptive Offset) feature will practically eliminate banding, even at 8-Bit. I wonder if this really holds up in reality :confused:

That is true for "Main" profile, but if I recall correctly the "High Efficiency" profile supports 12bit internal precision; even with 8bit source content.

[LoRd_MuldeR]

That is true for "Main" profile, but if I recall correctly the "High Efficiency" profile supports 12bit internal precision; even with 8bit source content.

Yup, but the first official specification of HEVC will be "Main" profile only. More profiles are to be added at a later time. We'll see which profile is going to be commonly supported...