x265 - Work already started?

[iwod]

http://code.google.com/p/x265/

https://github.com/chenm001/thevc

I was wondering why it isn't based or branch off from x264. Are they starting from scratch?

[poisondeathray]

There is a blog link on the google page, but it's in chinese

http://chenm003.blog.163.com/

There seems to be only 1 author/contributor ? Where are the other "usual suspects" ?

[LoRd_MuldeR]

Doesn't look like the "x265" project you are linking to is created by the people who created x264.

Also it's under an BSD license, which means they can't take any code from x264, which is under the GPL:
https://github.com/chenm001/thevc/blob/master/COPYING

(There is no "Copyleft" in the BSD license, which is an important idea of the GPL, so they are not compatible)


Finally we need some prove for those claims:
Simple and powerful HEVC/H.265 implement.
Optimize for embedded, FPGA, GPU, MultiCores system.

Given that h.265/HEVC has not even been officially released (scheduled for January 2013), I doubt their implementation is complete or even optimized yet ;)

(Maybe that implementation is based on an early draft version of h.265/HEVC)

[poisondeathray]

Wouldn't it be a better idea to join forces ??

What are the x264 dev's thoughts ?

[LoRd_MuldeR]

Update: Actually it appears that "x265" and "thevc" may be two different projects, just the x265 author is working on the latter too.

(So forget about my comment about the license issue, as x265 actually is (http://code.google.com/p/x265/source/browse/COPYING) GPL'd)

[hajj_3]

think the final draft of HEVC/H265 is out next month.

[burfadel]

Its kind of cheeky and a little deceiving to be using the name x265 if the projects are completely unrelated, because it would be human nature to expect it to be from the same authors and to the same quality as x264...

h265 is a long way off yet, as its target is a 50 percent improvement in the compression vs size. This is achievable, but requires large amounts of CPU. Also no point if the standard encode settings (and use for transmission) of h265 isn't much better than h264 for the same CPU usage. If you encode on tight x264 settings and the resultant size is say, 500MB, and you compress in h265 to the same CPU usage (may be low settings) and for the same quality its 500MB or larger, its a bit of a disadvantage.

That aside, to get 50 percent better than h264 it may encode at 0.17 fps compared to the 100 percent larger h264 (using x264) encoding at 25fps...

A note on the percentages above, seeing people online often misinterpret or incorrectly state percentages:
h265 half the size, is 50 percent better. Since its half h264, you need to double it to get back to h264 size, meaning 100 percent larger.

Processing requirements of h265 for its target size etc is one reason why it hasn't been released yet. Little point releasing something unusable that can be possibly improved if delayed :). h265 is probably the logical choice for future Ultra High Definition Television (UHDTV) transmission and distributable media (blu-ray etc), since its 7680×4320. It would also be the logical choice for Quad Full High Definition (QFHD) 3840×2160 if thats the future resolution instead of UHDTV.

Probably wouldn't have been a bad idea for these people to work on x264 and use what they can from it once the standard is released. At the moment, they could do a whole heap of work on h265 only to find they have to redo the whole lot if the standard changes before releasing :S

[hajj_3]

i'm sure fixed function hardware will make h265 fast to encode, just look at the speed of quicksync encoding and ati's upcoming equivalent. I'm sure ARM chips will be able to do it too but existing chips will indeed be very slow i'm sure. Hopefully existing hardware decode cpu/apu's might be able to add support to hardware decode h265 but can't see them being able to hardware encode h265.

[nm]

Hopefully existing hardware decode cpu/apu's might be able to add support to hardware decode h265
Not possible with current hardware. Most likely it will take a couple years before hw decoders start popping up in GPUs and other generic consumer devices. The format needs to be adopted widely first.

[iwod]

Well we can do the decoding with special Hardware. All Mobile Devices will force this to happen compared to previously they all try to use the CPU as much as possible.

Since UHDTV will have 4 times the pixel compare to 1080P Full HD, i wonder would 50% reduction be enough?

[Ghitulescu]

What is the goal of H.265?

[LoRd_MuldeR]

From Wikipedia:

Said to improve video quality and double the data compression ratio compared to H.264., HEVC can scale from 320 x 240 pixels all the way up to 7680 x 4320 resolution.HEVC aims to substantially improve coding efficiency compared to AVC High Profile, i.e. to reduce bitrate requirements by half with comparable image quality, at the expense of increased computational complexity. Depending on the application requirements, HEVC should be able to trade off computational complexity, compression rate, robustness to errors and processing delay time.

We'll see how much of that will hold true ;)

And we probably won't know until an H.265 encoder with the same level of optimizations as x264 has nowadays will be available - which can take years!

(Remember: There are enough "bad" H.264 encoders, which could easily lead to the conclusion the H.264 is worse than MPEG-4 ASP, if there weren't the "good" ones to prove the opposite)

[Ghitulescu]

If no "heavy" stays behind, the fate of H.265 will look alike the one of on6 codec, or any ogg ones. :(

[mandarinka]

Its kind of cheeky and a little deceiving to be using the name x265 if the projects are completely unrelated[...]

Note that x264 just applies an x letter to "h.264", most likely inspired by xvid. So continuing the tradition with x + h.265 is not particularly cheeky. It's an ambuitious name (much like x264 at the start when xvid was the choice codec), but that's it.

[Dark Shikari]

There seems to be a history of projects like this. For example, there was a Chinese developer who has been (for years) spam-mailing hundreds of video codec developers with his "H.265" codec which has absolutely nothing to do with the actual H.265.

[poisondeathray]

x265.nl , x265.com aren't registered domains yet . Maybe someone should register before someone makes a play

[mariush]

Well, I registered x265.net now.

If Dark Shikari or one of the x264 guys want to start on x265 sometimes in the future, I'll be willing to transfer it to them for free.

[iwod]

There seems to be a history of projects like this. For example, there was a Chinese developer who has been (for years) spam-mailing hundreds of video codec developers with his "H.265" codec which has absolutely nothing to do with the actual H.265.

So would we get an official x265 project? Since there is now even a x262

[Dark Shikari]

H.265 is quite different from H.264 in terms of structure; it'd be a pretty hefty modification.

But if someone really wants to try...

[hajj_3]

i think the only real advantage to most people is smaller filesize for the same quality, 700mb files would be far smaller. I can't see that many people using this for the higher quality as it would take ages to encode i'm sure. Needless to say i'd love to see an x265 real project :)

[CruNcher]

i would say from a consumer standpoint we can be pretty happy with what H.264 already accomplished in my terms it was the major first step in the right direction (though it also showed its "dark" side pretty obvious, and yes that's equivocally meant *wink* ) and many will follow though i don't see H.265 there (and don't feel like hyping around it) just for the sake of it but i guess it matters from your standpoint ;)

[shon3i]

@Dark Shikari, what happend with this (http://forum.doom9.org/showthread.php?t=154430) ? Can we see some results since there some H265 encoder.

[iwod]

i would say from a consumer standpoint we can be pretty happy with what H.264 already accomplished in my terms it was the major first step in the right direction (though it also showed its "dark" side pretty obvious, and yes that's equivocally meant *wink* ) and many will follow though i don't see H.265 there (and don't feel like hyping around it) just for the sake of it but i guess it matters from your standpoint ;)

It is merely the thought of having another standard to replace the Main Profile which is currently limited by Apple Devices. Since it is extremely unlikely we will get High Profile supported.

Also, starting ASAP, would means we can wait less before the implementations mature. It was merely my naive thoughts that extending x264 to support H.265 would be much faster, and like everything in life, easier said then done.

[nm]

It is merely the thought of having another standard to replace the Main Profile which is currently limited by Apple Devices. Since it is extremely unlikely we will get High Profile supported.
Both iPhone (starting with 3GS) and iPad 1 & 2 support High Profile H.264.

[amtm]

Though officially high profile support is only stated in the iPhone 4S and iPad 2 tech specs. The 3GS tech specs states baseline and the iPhone 4 and original iPad tech specs states main profile. Obviously whether they can support it contrary to the official specs is another matter.

[iwod]

Both iPhone (starting with 3GS) and iPad 1 & 2 support High Profile H.264.

Can anyone confirm that? I try a few google search and nothing meaningful turned up.

[LoRd_MuldeR]

That's what Apple says about the 4S:

Unterstützte Videoformate: H.264 Video: bis zu 1080p, 30 Bilder pro Sekunde, Main Level Profile Level 4.1 mit AAC-LC Audio bis zu 160 KBit/s, 48 kHz, Stereo-Audio in den Formaten .m4v, .mp4 und .mov; MPEG-4 Video: bis zu 2,5 MBit/s, 640 x 480 Pixel, 30 Bilder pro Sekunde, Simple Profile mit AAC-LC Audio bis zu 160 KBit/s, 48 kHz, Stereo-Audio in den Formaten .m4v, .mp4 und .mov; Motion JPEG (M-JPEG): bis zu 35 MBit/s, 1280 x 720 Pixel, 30 Bilder pro Sekunde, Audio im Format ulaw, PCM Stereo-Audio im Format .avi

Source: http://www.apple.com/de/iphone/specs.html

Though this doesn't mean it won't accept more than that in reality. They just don't guarantee more ;)

[JEEB]

Can anyone confirm that? I try a few google search and nothing meaningful turned up.
I can confirm this. iTunes used to stop you from transferring the files over, but if you got the files in using some other way, they would play on 3GS or newer (high profile, up to either level 4 or level 4.1).

[nm]

Can anyone confirm that? I try a few google search and nothing meaningful turned up.

What would be meaningful? Apple doesn't announce the support officially in their spec sheets, so you'll only have the word of mouth. But it's common knowledge by now:

http://forum.doom9.org/showthread.php?p=1330324#post1330324
http://forum.doom9.org/showthread.php?p=1453029#post1453029


That's what Apple says about the 4S:

Huh, the deutsch page has an error. They do claim High Profile support for 4S in other languages. From the english page (http://www.apple.com/iphone/specs.html):
Video formats supported: H.264 video up to 1080p, 30 frames per second, High Profile level 4.1 with AAC-LC audio up to 160 Kbps

[amtm]

That's what Apple says about the 4S:



Source: http://www.apple.com/de/iphone/specs.html

Though this doesn't mean it won't accept more than that in reality. They just don't guarantee more ;)

Then they haven't updated their German page. From the US page (http://www.apple.com/iphone/specs.html) about the iPhone 4S they list:

Video formats supported: H.264 video up to 1080p, 30 frames per second, High Profile level 4.1 with AAC-LC audio up to 160 Kbps,

[CruNcher]

Hehe interesting though wouldn't surprise me if they came up with the idea to make it a US Firmware feature only (there where already so crazy ideas in restriction stuff see Sonys escapade of device restrictions), though most likely someone of the Webmasters f***ed that up ;)

Hehe how funny is that http://www.apple.com/fr/iphone/specs.html the french only get Baseline sorry guys ;)
http://www.apple.com/de/iphone/specs.html <- Germany Main Profile (we contributed so much to H.264 and now we only get Main Profile screw you Apple, especially "Main Level Profile Level 4.1" whatever that is ;))
http://www.apple.com/nl/iphone/specs.html <- Netherlands High Profile
http://www.apple.com/no/iphone/specs.html <- Norway High Profile
http://www.apple.com/se/iphone/specs.html <- Sweden High Profile
http://www.apple.com/fi/iphone/specs.html <- Finland High Profile
http://www.apple.com/ru/iphone/specs.html <- Russia High Profile
http://www.apple.com/iphone/specs.html <- US High Profile
http://www.apple.com/ca/iphone/specs.html <- Canada High Profile
http://www.apple.com/uk/iphone/specs.html <- UK High Profile
http://www.apple.com.cn/iphone/specs.html <- China High Profile
http://www.apple.com/tw/iphone/specs.html <- Taiwan High Profile
http://www.apple.com/jp/iphone/specs.html <- Japan High Profile
http://www.apple.com/kr/iphone/specs.html <- Korea High Profile
http://www.apple.com/es/iphone/specs.html <- Spain High Profile

Anyway took Apple long enough to support High Profile officially @ all even if it was introduced silently with the 3GS already

[amtm]

Hehe interesting though wouldn't surprise me if they came up with the idea to make it a US Firmware feature only

Except it makes no sense? What would they gain by restricting German phones to only main profile other than huge headaches from having to maintain separate firmwares? It is sloppy updating and nothing more.

[CruNcher]

You don't need to maintain separate firmwares you could do it automatically based on the id of the current firmware, though as i said this is most probably really a webmaster fault especially the French Webmaster should be ashamed of himself ;)

[Kurtnoise]

Hehe how funny is that http://www.apple.com/fr/iphone/specs.html the french only get Baseline sorry guys ;)
where did you read this ?

Formats vidéo pris en charge : vidéo H.264 jusqu’à 1080p, 30 images par seconde, profil de référence jusqu’au niveau 4.1 avec son au format AAC-LC jusqu’à 160 kbit/s
==
Video formats supported: H.264 video up to 1080p, 30 frames per second, High Profile level 4.1 with AAC-LC audio up to 160 Kbps,

[CruNcher]

http://translate.google.com/#auto|en|Formats%20vid%C3%A9o%20pris%20en%20charge%20%3A%20vid%C3%A9o%20H.264%20jusqu%E2%80%99%C3%A0%201080p%2C%2030%20images%20par%20seconde%2C%20profil%20de%20r%C3%A9f%C3%A9rence%20jusqu%E2%80%99au%20niveau%204.1%20avec%20son%20au%20format%20AAC-LC%20jusqu%E2%80%99%C3%A0%20160%20kbit%2Fs

interesting it doesn't references anything in the text indeed i wonder where the algorithm or the Google Watson catched Baseline or Main Profile from and why :D

though for me "profile de reference" sounds like reference profile or another word to describe reference with would be the base nothing like High Profile http://translate.google.com/#auto|en|profil%20de%20r%C3%A9f%C3%A9rence i guess that's also what Googles Watson combines :D

shouldn't it be


Formats vidéo pris en charge : vidéo H.264 jusqu’à 1080p, 30 images par seconde, haut profil jusqu’au niveau 4.1 avec son au format AAC-LC jusqu’à 160 kbit/s

or


Formats vidéo pris en charge : vidéo H.264 jusqu’à 1080p, 30 images par seconde, profil de haut jusqu’au niveau 4.1 avec son au format AAC-LC jusqu’à 160 kbit/s

[PhrostByte]

A note on the percentages above, seeing people online often misinterpret or incorrectly state percentages:
h265 half the size, is 50 percent better. Since its half h264, you need to double it to get back to h264 size, meaning 100 percent larger.

Half the size does not mean 50 percent better. Does H.265 aim to give 50% more quality per bit, or files which use 50% the bits for the same quality? It makes a big difference.

50% better quality = 66% the size. (ie. 1400MB H.264 -> 933MB H.265)
100% better quality = 50% the size. (ie. 1400MB H.264 -> 700MB H.265)

[hajj_3]

it looks like some good progress on HEVC/H.265: http://www.h265.net/2012/02/final-meeting-notes-for-1st-to-7th-jct-vc-and-working-drafts.html

[iwod]

it looks like some good progress on HEVC/H.265: http://www.h265.net/2012/02/final-meeting-notes-for-1st-to-7th-jct-vc-and-working-drafts.html

Finally a update after a year of silence.

[Shevach]

I attended at two last HEVC meetings and have been monitoring HEVC activity since the project started.
Moreover I manage two threads on HEVC in LinkedIn.

HEVC is potentially better than H.264. Subjective tests ( were conducted by NTT DOCOMO, Inc) between HEVC (HM 5.0) and JM 18.2 shows that absolute majority of observers find HM5.0 at half the bit-rate to be comparable or better JM 18.2 .

There are reasons to believe that HEVC is significantly better than H.264.

1) 16x16, 32x32 transforms enable much better compression of large smooth regions.

2) SAO (Sample Adaptive Offset) - applied after deblocking, minimize "distance" between reconstructed and original frame.

3) Enhanced Intra Prediction - 32 angular modes, plus DC, Planar.

4) Enhancement of MV prediction (motion vector in HEVC is predicted from four spatial neighbors (top, top-right, left, left-bottom) and one co-located MV)

5) Imrovement of CABAC

[Atak_Snajpera]

I would like to see comparision between x264 --placebo and HEVC

[LoRd_MuldeR]

I would like to see comparision between x264 --placebo and HEVC

The problem is that there is not "the" HEVC. The same way there is not "the" H.264/AVC.

For a fair comparison we would need a HEVC encoder that is as optimized as x264 is nowadays (or at least somewhat close to that).

It will probably be easy to show that current x264 can beat a run-of-the-mill HEVC encoder...

[Shevach]

I would like to see comparision between x264 --placebo and HEVC

Rate Control in HM has not been implemented yet.

[Shevach]

I believe that HEVC is better than H264.
But how many "better" or what's HEVC (HM) gain against
H264? There are many figures (e.g. in JCTVC-H0116) but HM is compared against JM.

[gyth]

I would like to see comparision between x264 --placebo and HEVC
An easier test to arrange would be to compare x264 to JM 18.2 (the current version is listed as 18.3 (http://iphome.hhi.de/suehring/tml/)...?).
Not really a fair test, but could be interesting anyway.

[poisondeathray]

There are many figures (e.g. in JCTVC-H0116) but HM is compared against JM.

Wow, looks impressive so far

http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=4417

[iwod]

i was hopping many of the work on x264 could be used on x265, much like how x262 was born.

[IgorC]

From that link H.265 really compresses 2x more than H.264. http://phenix.it-sudparis.eu/jct/doc_end_user/documents/8_San%20Jose/wg11/JCTVC-H0116-v3.zip
Just in time there is a new audio format, a successor of HE-AAC/AAC. USAC.
USAC verification test report (http://mpeg.chiariglione.org/working_documents/mpeg-d/usac/USAC_vt.zip)

[hajj_3]

never heard of USAC, nice to see a better codec to HE-AAC though :)

The cost of AAC is a fortune to license i am told, multiple times more than the cost of licensing h.264. Lets hope that this will force a price reduction on aac then.

[amtm]

From that link H.265 really compresses 2x more than H.264. http://phenix.it-sudparis.eu/jct/doc_end_user/documents/8_San%20Jose/wg11/JCTVC-H0116-v3.zip

No, it compresses 2x more than the highly unoptimized JM encoder. JM hardly represents the highest compressibility possible for an H.264 encoder.

[IgorC]

Neither current reference h.265 encoder is optimal. So it's valid to compared two reference encoders to get a rough idea.


Lets hope that this will force a price reduction on aac then.
I wouldn't take a breath as licensing of MP3 doesn't get any cheap.

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

[Didée]

...subjective testing of HEVC compression capability ...
It shows impressive results ... In particular, > 50% bitrate reduction, 67% in class B (HDTV), 49% in class C (WVGA) => mission accomplished!
Until there's something to actually try, I'm suspicious of such numbers. Those are compairing reference encoders. I don't know about the quality of the HEVC reference encoder, but who knows, maybe it simply does a better job per se. The quality/efficiency of the JM reference encoder for AVC is known to be anything but impressive ...

Throwing some ballpark figures, x264 surely can cut bitrates by 50% compared to JM's AVC reference, in a breeze. :)

[kidjan]

Spec's released. Everybody start coding :P

From a certain standpoint, I feel like H.265 is a carrot on a stick that actually doesn't have a lot of value for anyone.

The biggest issue with it, obviously, is the complete and total lack of embedded/hardware support. There is no hardware support in any device currently sold that I'm aware of, which means there's something like a billion phones in circulation that are incompatible with the format. Which means encoding your content to this format is really pointless.

Second, the lack of encoder maturity is also a big turn off. If x264 demonstrated one thing very clearly, it's that the codec used isn't nearly as important as the thoughtfulness of the encoder implementation. So from my standpoint, it's just a bad attempt to squeeze some more royalties out of consumers by obsoleting a format that is frankly not obsolete.

[paradoxical]

The biggest issue with it, obviously, is the complete and total lack of embedded/hardware support. There is no hardware support in any device currently sold that I'm aware of, which means there's something like a billion phones in circulation that are incompatible with the format. Which means encoding your content to this format is really pointless.

Second, the lack of encoder maturity is also a big turn off. If x264 demonstrated one thing very clearly, it's that the codec used isn't nearly as important as the thoughtfulness of the encoder implementation. So from my standpoint, it's just a bad attempt to squeeze some more royalties out of consumers by obsoleting a format that is frankly not obsolete.

And yet, all of this was being said by people when H.264 was ratified. Hardware support took many years to become as ubiquitous as it is. x264 didn't become as mature as it is now until many years after the standard came out. By this logic, we should have just stuck to MPEG-1 video.

[JEEB]

Spec's released. Everybody start coding :P
...and where is it released, other than drafts? As far as I know, HEVC has not gone through the FDIS ballot yet, it passed the DIS ballot on January 8th. The current versions of the 10th draft are available here (http://phenix.int-evry.fr/jct/doc_end_user/current_document.php?id=7243), and that is what going to end up being pushed to the FDIS ballot after being finished up, as is noted by the name of the document: 'High Efficiency Video Coding (HEVC) text specification draft 10 (for FDIS & Consent)'.

If you mean the news about HEVC being officially named over at the ITU-T, yeah... That is exactly what it is. They decided that they will vote for it in the standardization FDIS ballot, and that it will get the ITU-T naming of H.265. Yet people really seem to take it out of context a lot :P .

Anyways, I'd guess that people would start moving a bit more after the final version of Draft 10 gets released, which would pretty much be what will get then released, as you can only do minor editing after the FDIS ballot is started. Also for really proper development one would need something to test his work against, say, a reference implementation.

Enter HM, currently at version 9.2 and under active development. It currently does not match up with the under-work 'HEVC Version 1' specification, and is expected to mostly match to it after version 10.0 gets released. But I suspect it will take some extra time for it to become generally 'fully' compatible with the text specification.

That said, Smarter's decoder, and another decoder/encoder project I know of (not the x265 that one Chinese dude started) have already started development, but esp. the latter project is having problems because HM is not matching the specification.

[Asmodian]

By this logic, we should have just stuck to MPEG-1 video.

Well maybe MPEG-2, at least I don't remember a mature MPEG-1 encoder that was better than early implementations of MPEG-2. ;)

I wouldn't call the release of new spec's obsoleting H.264, after all MPEG-2 isn't really obsolete, at least it is very widely supported and new content is still being released in it.

[paradoxical]

I wouldn't call the release of new spec's obsoleting H.264, after all MPEG-2 isn't really obsolete, at least it is very widely supported and new content is still being released in it.

Yep, still used overwhelmingly for US digital TV. And the quality suffers all the more for it, too.

[Asmodian]

Well maybe MPEG-2 should be obsolete but I wouldn't worry about devices dropping support for H.264 yet.

[hajj_3]

My prediction is that HEVC will give us more something like a 25% compression improvement, and probably mainly for high resolution content... Considering how much more cycles it eats, and that high resolution content takes ages to encode to begin with, its use is imo questionable, even more so considering that we don't know if 8k (and higher) will find widespread acceptance by the consumers or if it will go the way of high definition audio for music (SACD, Audio DVD...). As storage and bandwidth is growing I don't see much need for better compression than we have now with x264, at least not at the costs of the need for new encoding/decoder hardware and time (CPU cycles). Just my 2 cents :) *Back to IDLE mode*

x264 is already beaten with the hevc reference encoder, the reference encoder of AVC was poor so imagine how good an x265 encoder will be in a few years time.

Also most broadcasters don't use x264 they use commercial versions so hevc will be significantly better than the h264 that they currently use. BSkyB have been involved in HEVC so its pretty clear that sky in multiple uk countries will switch to hevc at some point. As for requiring new hardware... some nvidia/amd gpu's might be able to hardware decode using the programmable parts of the gpu. h264 was slow on cpu's for a long time so i think hevc will be a pretty big success.

sacd references are pointless as it is difficult to hear the differences whereas halving the bitrate is a dramatic change.

[LoRd_MuldeR]

x264 is already beaten with the hevc reference encoder, the reference encoder of AVC was poor so imagine how good an x265 encoder will be in a few years time.

In what way is it beaten? AFAIK the HEVC reference encoder runs extremely slow, as is expected for a reference encoder. So even if it could beat x264 quality-wise (at the same bitrate!), we cannot use it practically. So unless we get something that runs at reasonable speed (i.e. not significant slower than x264) it would be kind of a "theoretical" success with no practical relevance. Furtheron PSNR or SSIM numbers are one thing, but I'm yet to see an in-depth visual comparison of the HEVC reference encoder and x264.

Another point to consider: The better the reference encoder performs, the more difficult it will be for "alternative" implementations to actually improve over the reference encoder...

[Atak_Snajpera]

i hope that hevc won't be another 'jpeg2000' , 'jpeg-xr' , 'webp'. All those formats offer higher compression than jpeg but our digital cameras still use older technology.

25 - 33 % bitrate savings may not be enough for many companies to convince them to make additional investments in new hardware. especially when they just upgraded from mpeg2 to h.264.

[LoRd_MuldeR]

With the much higher amount of data for "4K" or even "8K" content, those 33% may be more important. And I guess it will require "hardware upgrades" anyway. Not that delivering "4K" content to end-users makes much of a sense. But after "3D" has become more or less standard and the big hype is fading slowly, it seems "4K" will be the next hype...

[Atak_Snajpera]

I can't wait to see 576i upscaled to 4K ;) Even now I'm very disappointed that so many shows are still being recorded in SD. So what that your TV reports video stream as 1080i if this is just upscaled version. This is very common in Poland. For me 4K is just another hype like 3D.

[edison]

With the much higher amount of data for "4K" or even "8K" content, those 33% may be more important. And I guess it will require "hardware upgrades" anyway. Not that delivering "4K" content to end-users makes much of a sense. But after "3D" has become more or less standard and the big hype is fading slowly, it seems "4K" will be the next hype...

I think there will be an another new encode tech for 8k content .

[benwaggoner]

25 - 33 % bitrate savings may not be enough for many companies to convince them to make additional investments in new hardware. especially when they just upgraded from mpeg2 to h.264.
Yeah, I'd say it takes at least a 50% improvement to drive a big industry-wide shift.

MPEG-2 was easily 50% better than MPEG-1 for interlaced content (which the bulk at the time).

But MPEG-4 part 2 was perhaps only a 30% improvement from MPEG-2, and didn't get broad industry support.

H.264 offered >>50% improvement compared to MPEG-2. But even there we see industries like cable still using mostly MPEG-2 due to all the old STBs out there.

[JEEB]

While I do agree that traditional broadcasting most probably is not going to be switching over to HEVC too quickly*, I must say that it doesn't exactly look like MPEG-4 Visual to me.

As far as I can remember, first of all MPEG-4 Visual never got used by ITU-T (thus not having a recommendation code on that side of things). Adding to that, it came relatively soon after MPEG-2 Video, which was IIRC '95 (MPEG-4 Visual came in '99), and the business was just in the middle of moving towards the first one with DVD video, first-gen digital television standards and so forth. Then, looking at the whole MPEG-4 Visual specification, it just feels like a mess; a lot of semi-cool features stuffed into a format while not really gaining that much from them than from some more "traditional" takes at compression. Not to mention that while H.263 did seemingly have in-loop deblocking, this was not present in MPEG-4 Visual for whatever reason. One of the relatively good WTF-listings regarding MPEG-4 Visual is here (http://guru.multimedia.cx/15-reasons-why-mpeg4-sucks/).

Looking at it after-the-fact, in a sense MPEG-4 AVC was really a kind of "Oh, so you just want the usual kind of thing after all?" format, which did actually work well as we have all seen. And HEVC takes it even further, with features that generally seem to be found to be good ideas by other formats that have come up lately, without going all out on "goofy" things like MPEG-4 Visual did.

What I am trying to say here is that while HEVC probably is not going to blow anyone's mind any time soon, comparing it to MPEG-4 Visual is kind of... not right in my opinion, as it already has gone further than MPEG-4 Visual ever did in the specification space regarding adoption.

* No-one wants to have customers crying over why they have to buy new TV sets or receiver boxes just to watch TV, only ~10 years after the last digital'ization was done -- or even less depending on the country and whether or not there was a switch towards AVC + 1080i/p lately.

[benwaggoner]

What I am trying to say here is that while HEVC probably is not going to blow anyone's mind any time soon, comparing it to MPEG-4 Visual is kind of... not right in my opinion, as it already has gone further than MPEG-4 Visual ever did in the specification space regarding adoption.
FWIW, I agree with everything you say there. Every indication at this point is that HEVC is going to be a big enough improvement for it to see broad industry adoption.

Speaking for myself, I expect that most or all practical 4K home video will be HEVC only. It'd be crazy to do anything else given HEVC's advantages at higher frame sizes, and new decoders are going to be needed anyway.

[xooyoozoo]

There was a recent paper published (https://ece.uwaterloo.ca/~z70wang/publications/vpqm13.pdf) detailing HEVC's subjective improvements over H264. The paper is more focused on objective metrics (psnr, etc) and spatial vs temporal distortions rather than the encoders themselves, but it still gives good data relevant to us. It also doesn't give any numbers the JCT docs haven't, but the fact that it's co-authored by Zhou Wang (SSIM's original creator) makes it inherently more quotable. ;)

Long story short is that 'state-of-the-art' objective metrics vastly underestimate HEVC, and with 1080p material (class B), HEVC can produce the same subjective quality for 1/3 of H264's filesize:

http://i.imgur.com/PhBWZKZ.png

There was also a more cursory subjective test (http://infoscience.epfl.ch/record/180494/files/hanhart_SPIE2012_1.pdf) last year on 4K clips. On some of clips, HEVC managed the same quality at 25% of H264's bitrate!

'Real' encoders would obviously have numerous improvements* over the JM used here, and one cannot assume that porting these improvements over to the HM would yield similarly proportionate gains. However, the massive gains shown for high resolution content sure does leave a large buffer zone for all the confounding variables to work things out. :D

*which I think are almost always overstated in these discussions. Looking only at quality per bit, reference encoders suck because they don't come with a steering wheel, not because something's wrong with the engine.

Edit: Forgot to link this fairly important bit from the first paper. Analyzing still-shots of an HEVC clip will also underestimate its overall performance:

http://i.imgur.com/46BlCil.png

[Warperus]

Is there any HEVC recommendation available to public (without subscriptions/payments)?

[drmpeg]

Is there any HEVC recommendation available to public (without subscriptions/payments)?

Here's the latest edits.

http://phenix.int-evry.fr/jct/doc_end_user/current_document.php?id=7243

Ron

[Warperus]

Thank you, drmpeg.

[JEEB]

By the way: why are so many users here still referring to "HEVC"? It's officialy called "H.265" now, isn't it?
ISO/IEC name is still (MPEG-H) HEVC, H.265 is the ITU-T's name for it, only given to it lately (before that it was marked as ITU-T H.HEVC there).

Just like (MPEG-4) AVC is the ISO/IEC name for what is called H.264 over at the ITU-T.

[Biggiesized]

H.HEVC might have been a working name like H.26L.

[JEEB]

H.HEVC might have been a working name like H.26L.
It was indeed. Since numbers are usually only given relatively close to finalization of the specification (although yes, it still isn't finished).

In any case, my point was that both HEVC and H.265 are valid names for the format :) (I generally will be calling it HEVC because that's how I've been calling it for the past XY months, and the fact that it gained another nickname isn't going to change much of that habit)

[pandy]

Can't wait for x265 then :).

https://code.google.com/p/x265/


@ x264 developers:

Can you please stop working on x264 and put all your workforce into x265 (or whatever you wanna call it) from now on :cool::D;)?

What with interlace? And how fast your CPU is clocked? 12GHz?

[aegisofrime]

https://code.google.com/p/x265/



What with interlace? And how fast your CPU is clocked? 12GHz?

AFAIK that isn't "real" x265 though. The developer isn't part of the x264 team like Dark Shikari, akupenguin et al. I wonder what will DS et al call their implementation of HEVC now?

[easyfab]

AFAIK that isn't "real" x265 though. The developer isn't part of the x264 team like Dark Shikari, akupenguin et al. I wonder what will DS et al call their implementation of HEVC now?

Are you really sure that x264 team will do a HEVC encoder ?

[aegisofrime]

Are you really sure that x264 team will do a HEVC encoder ?

Nope I'm not sure at all. AFAIK DS has not commented on the issue. I'm just saying that the x265 linked is not done by the x264 developers.

[Sagittaire]

anyway the work for x264 is incredible ... perhaps time for other dev to work to x265.

[LigH]

Hype victim.

There are very few people willing to spend a week on a movie just to be a "pioneer" using a bleeding edge technology, not understanding that most consumers and casual users will demand a conversion being faster than playing time.

Give the developers the time they need to really understand the concepts, even before they start implementing half-baked code. A good software project is started in theory, and it is "almost done" (regarding its definition) before the first line of code starts. The less you know where you go, the more often you have to go back because you took a wrong turn.

[Audionut]

Not to mention, afaik, it was over 12months after version 1 of H.264 before the first commit of x264. And x264 was not fast initially.

Have we even got a final draft of HEVC yet?
I guess people these days are less patient.

[LigH]

They never had the joy of manually tweaking DivX ;) 3.11α SBC parameters in Nandub until there were no "shit frames" left...

[pandy]

What do you mean with "What with interlace?"?




:rolleyes:


H.265 is designed for progressive video - mostly those with higher resolution in mind (4k and 8k)


So you're saying a 12 GHz CPU is needed to decode H.265 :rolleyes:?


Today probably yes especially for 4k content (8 k for sure) - count H.265 as 4 - 16 times more demanding than H.264 for CPU speed.


Also: the sooner the adoption of H.265 starts, the more likely it would be that there would be dedicated hardware to decode H.265. So a CPU might not even be necessary if NVIDIA or AMD for example would develop some VPUs capable of decoding H.265 ;).

Seriously, just look at those numbers posted by "xooyoozoo":




They sound amazing IMHO. So why not screw H.264 from now on and go for H.265 instead :p?

But why - is see no point to go for H.265 for HD - it have sense for Ultra HD however until moderate priced displays for 4k will be not present then i don't see any gain for H.265 over H.264.

[aegisofrime]

So H.265 does not support interlacing?

That would be awesome :).

Interlacing is a very evil thing IMHO and should have been abandoned a long time ago.

So, if H.265 drops interlacing support, then this actually is very much appreciated :).


They can drop it as long as we get high frame rates.

Recently there's a disturbing trend of some DVDs coming out with 30p content. In this case, I actually prefer 30i as I can deinterlace it with QTGMC to get nice 60p content. With 30p, the best I can do is to double the framerate with Interframe, and the results are not as good as deinterlacing 30i with QTGMC.

[sneaker_ger]

H.265 still supports flagging content as interlaced - it just doesn't have any interlaced tools like PAFF or MBAFF anymore AFAIK.

[Guest]

Guys, debating interlacing versus progressive is off topic here. Further such posts will be deleted.

[IanB]

Split the debate crap off into it's own thread, it's spoiling an interesting thread.

[kidjan]

And yet, all of this was being said by people when H.264 was ratified. Hardware support took many years to become as ubiquitous as it is. x264 didn't become as mature as it is now until many years after the standard came out. By this logic, we should have just stuck to MPEG-1 video.

Except there wasn't an existing base of billions of phones capable of decoding MPEG-1, and MPEG-1 was obviously a pretty basic standard comparatively speaking. Right now there are literally billions of embedded devices with hardware capability for H.264; it's a completely different situation if you take magnitude and proliferation into account, not to mention the relative maturity of H.264 when compared to something like MPEG-1 (please, no comparison)

[kidjan]

My prediction is that HEVC will give us more something like a 25% compression improvement, and probably mainly for high resolution content... Considering how much more cycles it eats, and that high resolution content takes ages to encode to begin with, its use is imo questionable, even more so considering that we don't know if 8k (and higher) will find widespread acceptance by the consumers or if it will go the way of high definition audio for music (SACD, Audio DVD...). As storage and bandwidth is growing I don't see much need for better compression than we have now with x264, at least not at the costs of the need for new encoding/decoder hardware and time (CPU cycles). Just my 2 cents :) *Back to IDLE mode*

...and that isn't even beginning to broach the whole patent subject. HEVC basically resets the clock on royalties.

[paradoxical]

Except there wasn't an existing base of billions of phones capable of decoding MPEG-1, and MPEG-1 was obviously a pretty basic standard comparatively speaking. Right now there are literally billions of embedded devices with hardware capability for H.264; it's a completely different situation if you take magnitude and proliferation into account, not to mention the relative maturity of H.264 when compared to something like MPEG-1 (please, no comparison)

There were more than a billion VCRs sold when DVD came out. There were more than a billion DVD players sold when BluRay came out. Did you fight against those things coming out as well? I really don't see how it's a different scenario other than you've just made an arbitrary line. H.264 deserves no special place of being considered irreplaceable versus any other video codec or format.

[me7]

When you compare the situation with SACD and DVD-A, remember that the CD has practically surpassed human hearing and all of these formats don't offer any practical advantage.
Right now, people love streaming high resolution videos over the internet. The quality is usually so bad that I'd roughly compare it to audio cassettes. A new video codec that improves the bad quality of youtube videos could have a similar impact as the CD had. People are ready for it, even my non-tech-savvy friends stream 1080p videos from youtube every day.

[xooyoozoo]

I really don't see how it's a different scenario other than you've just made an arbitrary line. H.264 deserves no special place of being considered irreplaceable versus any other video codec or format.

I also think it's a "different" scenario, but in an entirely opposite way.

Back then, my laptop couldn't handle H.264 properly. Do I buy a new laptop? No, I do so a few years later because it's a fully-functional laptop. Nowadays, my phone won't handle H.265. Do I buy a new phone? Well, yea duh, give me 8 months for my contract to end.

That's the what the appliancization of hardware has led to, and with some of the biggest (http://pro.gigaom.com/blog/intels-over-the-top-compression/) mobile (http://reviews.cnet.com/8301-13970_7-57387626-78/qualcomm-shows-horsepower-of-next-gen-h.265-video/) players (http://www.tweaktown.com/news/27733/broadcom_s_new_chip_supports_h_265_ultrahd/index.html) brawling for market share and carrier** support using whatever technological leverage they can, I doubt it'd even be possible to get any decent mobile gadget next year without H.265.

**at least in the US, this will singlehandedly ensure quick and peaceful media progressions for the next cycle or two. They love, NEED, the efficiency. "Oh you don't have H.265? Why don't we put your gadget back in the corner over here."

[LigH]

I wish it was just as simple with Ogg Vorbis. Sometimes I wonder if a competitor pays for not mentioning it in the list of supported formats (I know several devices which support Ogg Vorbis audio, but their manufacturers don't advertize that).

Marketing will have an important impact. The MPEG-LA has the power. DivX had a little less. Xiph hardly any. The popularity does not reflect the results of technical comparisons regarding quality and efficiency...

[kadajawi]

Not sure if that was posted here before, but some researchers (?) claim that h265 decoding can be done on an iPad for example.

http://www.v-net.tv/hevc-capable-devices-hit-1b-in-2012-ahead-of-standard/

Only needs a software update.

I think once decent encoders become available, and if device support really comes that fast (though the question is if the encoding settings need to be reduced in order to make it playable...), h265 will be used. It is useful everywhere. My connection is not even good enough for 480p at YouTube (mostly I use 240...), so if they can pack in 480p in a 240p sized stream, that would be awesome. The 720p/1080p people stream on demand is not very good in quality, if the same bandwidth can give better quality, I think it'd be quite popular.

[pieter3d]

At the JCT-VC meetings there was a demo of 1080p HEVC playback on an iPhone5, pure software decode.

[vivan]

It is useful everywhere. My connection is not even good enough for 480p at YouTube (mostly I use 240...), so if they can pack in 480p in a 240p sized stream, that would be awesome. The 720p/1080p people stream on demand is not very good in quality, if the same bandwidth can give better quality, I think it'd be quite popular.It's just because of youtube crappy encoder, not because of H.264. H.265 wouldn't really change anything there - if they wanted, they could improve quality a lot even with H.264.

[foxyshadis]

Not sure if that was posted here before, but some researchers (?) claim that h265 decoding can be done on an iPad for example.

http://www.v-net.tv/hevc-capable-devices-hit-1b-in-2012-ahead-of-standard/

Only needs a software update.

HEVC will never catch on as a software-only update on current devices. It would just eat battery too quickly to be useful, although the newest phones and pads would be able to use multicore decoding and get some improvement, and one or two might figure out how to leverage the GPU for some steps. It will never reach ubiquity until it's baked into hardware, just like AVC, and just like MP3 and MP4 audio before it. At best, a small portion of people will use it for personal collections and a few companies will integrated it into streaming apps, but it will remain niche until battery consumption issues are solved.

It's too bad, because I'd love it if it rolled out everywhere today, particularly the still image part.

[sneaker_ger]

Fraunhofer HHI has presented a software HEVC decoder supporting Main and Main 10 profile on the CeBIT. Allegedly "a single core" is sufficient for 1080p50, "four cores" for 2160p50 (4k). (Their test sequences were really low bitrate, so take it with a grain of salt...)

http://www.hhi.fraunhofer.de/en/media/press/cebit-2013.html?NL=0
http://www.heise.de/newsticker/meldung/Videostandard-H-265-HEVC-in-Aktion-1817722.html (German, English auto translation (http://translate.google.de/translate?hl=de&sl=de&tl=en&u=http%3A%2F%2Fwww.heise.de%2Fnewsticker%2Fmeldung%2FVideostandard-H-265-HEVC-in-Aktion-1817722.html))

[IgorC]

The situation around HEVC is different from H.264's 10 years ago.

Chipmakers were already prepraring HEVC acceleation.
Hardware video decoder gets only small area of chip and today even mobile GPU are much more powerful than that.
Considering that HEVC is 3-4 times more complex and that each new node (32 nm, 22nm... etc) gets 2x more power efficient, HEVC hardware decoding on 20-22 nm chip will consume the same amount of power as H.264 on 40-45 nm chip.
Even 28 nm chips would have a long bttery life.

As an example, the last Atom CPUs (32 nm) have no issues with harware decoding of Blu-Ray (H.264 High Profile). I have tried to play two Blu-Ray streams at the same time (or any other x264 encodes at high bitrate) on Atom N2600 (CPU+GPU TDP 3.5 W), zero dropped frames.

[Sagittaire]

The situation around HEVC is different from H.264's 10 years ago.
As an example, the last Atom CPUs (32 nm) have no issues with harware decoding of Blu-Ray (H.264 High Profile). I have tried to play two Blu-Ray streams at the same time (or any other x264 encodes at high bitrate) on Atom N2600 (CPU+GPU TDP 3.5 W), zero dropped frames.

Well no problem with ARM too but it's hardware decoding (GPU). Atom (CPU) can't decode two 1080p BD H264 stream with softwate decoding.

[Nil Einne]

Except there wasn't an existing base of billions of phones capable of decoding MPEG-1, and MPEG-1 was obviously a pretty basic standard comparatively speaking. Right now there are literally billions of embedded devices with hardware capability for H.264; it's a completely different situation if you take magnitude and proliferation into account, not to mention the relative maturity of H.264 when compared to something like MPEG-1 (please, no comparison)

But the thing with smartphones and perhaps tablets to a slightly lesser extent is they tend to have a short lifespan. Even less so then computers I would say. Most people probably keep their phones for at most 2-3 years, even if they're cheap ones and/or unsubsidised. Amongst other things, by that time the battery starts to die out and while many phones do have replaceable batteries, many people don't bother. So if it takes 2-3 years for most phones to have H265 support, we get most phones supporting in 4-6 years which is a fairly long time, but not that long.

BTW, for the person who mentioned royalties, I would say the MPEG-LA didn't get to where they are today by being stupid. Presuming there must be one of VP9 or Daala or something else (Intel/Real NGV perhaps?) which will be sufficiently improved over H264, even if not able to compete with H265, they have to be careful not to price themselves out of the market. As others have said, there are plenty of areas, particularly streaming videos and legal downloads where plenty of people would love to have smaller files or higher quality even for 1080p. Bandwidth is improving, but not that fast.

[K.i.N.G]

Hype victim.

There are very few people willing to spend a week on a movie.

Not really, if the gains are big enough.

Do you know how long it takes to render a photorealistic image for some architecual design (what i partially do for a living), not to mention render special effects for some movie or an entire CG movie?

It always makes me smile when i see some comments on here from ppl complaining about 2fps encodes on their laptops.

A movie only needs to be encoded once for disc distribution. After that its just copies. So what even if it takes a whole weekend. Is that really such a big problem??

Sure, broadcasting and other areas where realtime encodes might be required is another story but i dont think thats the current target they have in mind. H264 is still more than capable (as mentioned many times here already). Its not because there is H265 that you suddenly arent allowed to use H264 anymore... And when the hardware catches up, switch to H265 if you want.

[kolak]

Few days is way to long. One night is maximum.

[kidjan]

There were more than a billion VCRs sold when DVD came out. There were more than a billion DVD players sold when BluRay came out. Did you fight against those things coming out as well? I really don't see how it's a different scenario other than you've just made an arbitrary line. H.264 deserves no special place of being considered irreplaceable versus any other video codec or format.

You're talking about the past. I'm talking about now. Apples and oranges.

Facts:

1. H.264 is still technically advanced--we're not talking about VCR or DVD quality, and to the best of my knowledge, very few people complain about well-encoded H.264 at 1080p. 4k, sure, whatever, but we're reaching a point of pretty significant diminishing returns, in my opinion. I don't get the impression the typical consumer cares.
2. H.264 has royalty issues. Those go away if you wait long enough. For how long are we planning on letting MPEG-LA hold companies over a barrel? At what point does optimizing along codecs no longer matter when bandwidth and storage space are consistently becoming less of an issue? (and if you think this is nonsense, consider nobody's really seriously cared about updating JPEG for a solid twenty years--because the savings simply don't justify the pain of updating the world)
3. Unlike previous codecs, H.264 really does enjoy an unprecedented amount of support. I cannot think of a previous format that is as ubiquitous. That alone makes it very hard to migrate away from: moving to something with effectively zero support while still maintaining support for old products isn't trivial.

I think over time, yes, H.265 and/or VP8 and/or VP9 will enjoy hardware support, but given the proliferation of H.264...codified as a standard among Windows 7, OSX, iOS, android, blue-ray formats, and so on....that's going to be a lot more difficult than it's previously been, particularly given that the value-add (making already great looking video look....better?) is hard to communicate to a typical customer.

My point really boils down to: there's a diminishing return on investment with these video codecs, particularly given some realities about royalties, network speeds, storage requirements and so forth. I feel we're already near it with H.264, and at some point....it's just a royalties carrot on a stick.

[benwaggoner]

1. H.264 is still technically advanced--we're not talking about VCR or DVD quality, and to the best of my knowledge, very few people complain about well-encoded H.264 at 1080p. 4k, sure, whatever, but we're reaching a point of pretty significant diminishing returns, in my opinion. I don't get the impression the typical consumer cares.
Consumers don't even know about bitrate directly. However better compression makes for better quality at given bandwidth (which can enable new features like 3D and 4K), or lower bandwidth at the same quality, or a mix of the two. As metered and capped bandwidth becomes more common, more efficient compression will always be useful.

HEVC will also bring 10-bit decoding mainstream; a quality improvement that H.264 High Profile can't deliver at any bitrate.

2. H.264 has royalty issues. Those go away if you wait long enough. For how long are we planning on letting MPEG-LA hold companies over a barrel? At what point does optimizing along codecs no longer matter when bandwidth and storage space are consistently becoming less of an issue? (and if you think this is nonsense, consider nobody's really seriously cared about updating JPEG for a solid twenty years--because the savings simply don't justify the pain of updating the world)
H.264's royalty issues are primarily theoretical and philosophical. I'm not aware of any business and usage models that haven't emerged due to the MPEG-LA licensing terms. Clearly the H.264 licensing costs are far, far less important than the cost savings from more efficient encoding. Otherwise Theora would have mattered.

3. Unlike previous codecs, H.264 really does enjoy an unprecedented amount of support. I cannot think of a previous format that is as ubiquitous. That alone makes it very hard to migrate away from: moving to something with effectively zero support while still maintaining support for old products isn't trivial.
MPEG-2 was more ubiquitous than any codec before or since. It probably counted for >98% of eyeball hours of digital video last decade. DVD+cable+sat+ATSC+DVB were all MPEG-2, and are still mainly MPEG-2.

MPEG-2 will still be widely used alongside H.264 and HEVC throughout this decade.

I think over time, yes, H.265 and/or VP8 and/or VP9 will enjoy hardware support, but given the proliferation of H.264...codified as a standard among Windows 7, OSX, iOS, android, blue-ray formats, and so on....that's going to be a lot more difficult than it's previously been, particularly given that the value-add (making already great looking video look....better?) is hard to communicate to a typical customer.
Again, it's not something that the customer would even know about. How many people know what Profile @ Level their handsets support today :)? But if you're a wireless carrier and blanching at the CAPEX predictions to handle the huge growth of wireless video, you're going to want every handset on your network to be able to consume the lowest bandwidth streams possible. Same with content distributors, who drop support for devices with less-capable decoders whenever they can get away with it.

Plus it's cheap to add another decoder to GPUs and processors, and getting cheaper every generation. Adding HEVC would increase device COGS by way less than higher clock speed or extra cores. The days of $100+ deadicated MPEG-2 cards is way gone. All video decoders take up a really small and shrinking area of the silicon on today's chips.

My point really boils down to: there's a diminishing return on investment with these video codecs, particularly given some realities about royalties, network speeds, storage requirements and so forth. I feel we're already near it with H.264, and at some point....it's just a royalties carrot on a stick.
If compression efficiency doesn't matter, how come the industry is continuously making big investments to improve their existing MPEG-2 and H.264 encoders? A 10% compression efficiency improvement is 10% more channels for Comcast, Dish, etcetera, and that makes for significant revenue for them.

Honestly, the H.264 royalties are barely a rounding error compared to what a content delivery company pays for their encoders, service, staff to maintain them, bandwidth, etcetera. HEVC royalties could be 10x as much as H.264 and would still be a huge net payoff just from bandwidth and storage savings.

The critical thing is that per-decoder license fees stay reasonable.

[kieranrk]

I agree to an extent but I don't think the addressable market will be anywhere as big as with MPEG-2 or AVC. Only green-field deployments and 4K are going to use it for DTH broadcasting, though a few European governments are mandating it.

Only web (including mobile) are going to be big consumers of HEVC and arguably the web doesn't have serious video bandwidth restrictions anyway. ARPU for web video is very low anyway.

HEVC won't bring 10-bit mainstream. There's a huge push against it from hardware manufacturers.

HEVC royalties could be 10x as much as H.264 and would still be a huge net payoff just from bandwidth and storage savings.
This is definitely not the case for operator-loaned STBs.

[benwaggoner]

I agree to an extent but I don't think the addressable market will be anywhere as big as with MPEG-2 or AVC. Only green-field deployments and 4K are going to use it for DTH broadcasting, though a few European governments are mandating it.
For OTA, broadcasting, sure. Huge decoder switching costs, which is why most of that is MPEG-2. South Korea has already done two rounds of OTA HEVC 4K already, though.

I think OTA is a pretty small and shrinking slice of viewership, though.

Only web (including mobile) are going to be big consumers of HEVC and arguably the web doesn't have serious video bandwidth restrictions anyway.
That is an argument you'd have to actually make. Until everyone in a household can reliably get 15 Mbps streams simultaneously, the web has serious bandwidth restrictions.

HEVC won't bring 10-bit mainstream. There's a huge push against it from hardware manufacturers.
Citation? That's not what I'm hearing for living-room devices. Mobile doesn't seem to have nearly as much taste for 10-bit, certainly.

This is definitely not the case for operator-loaned STBs.
Huge switching costs there, which is why they're mostly still getting MPEG-2 anyway. The bandwidth savings of MPEG-2 -> HEVC could make STB replacement cost-effective, however.

But video decoder license fees are a small fraction of a STB's cost, and are a lot higher and uncapped for MPEG-2 anyway. If license fees were a big deal, people would have stopped shipping MPEG-2 decode a long time ago (note that it's not in Win8 by default now). VC-1 and H.264 were both much, much cheaper at the time.

[kieranrk]

For OTA, broadcasting, sure. Huge decoder switching costs, which is why most of that is MPEG-2. South Korea has already done two rounds of OTA HEVC 4K already, though.

I think OTA is a pretty small and shrinking slice of viewership, though.

That is an argument you'd have to actually make. Until everyone in a household can reliably get 15 Mbps streams simultaneously, the web has serious bandwidth restrictions.


Improved compression isn't holding back any major product developments that will cause a significant revenue stream for web video (though perhaps so for mobile) - it's why a lot of places are happy sending the junk from Elemental "GPU" encoders after all. Apart from being an incremental improvement, what new revenue streams will HEVC bring in? H.264 brought in HD video on the web but in my opinion HEVC brings no new products to the table. I guess there's a possibility for 4K but I would imagine Hollywood would want to charge a premium for that and not give it away to Netflix. It's the same with MPEG-DASH; deployment is sluggish since the benefits don't appear to be financially worthwhile.

In most of the world STBs last for ~10 years or so; Korea is the special case in that there is a short upgrade period. All the more so when people have a lot of PVR'd recordings that can't be easily moved between STB (Device specific DRM).


Citation? That's not what I'm hearing for living-room devices. Mobile doesn't seem to have nearly as much taste for 10-bit, certainly.


I think it's public knowledge that there's a row going on about this in DVB, which will in effect set the global agenda for living room devices.


Huge switching costs there, which is why they're mostly still getting MPEG-2 anyway. The bandwidth savings of MPEG-2 -> HEVC could make STB replacement cost-effective, however.

But video decoder license fees are a small fraction of a STB's cost, and are a lot higher and uncapped for MPEG-2 anyway. If license fees were a big deal, people would have stopped shipping MPEG-2 decode a long time ago (note that it's not in Win8 by default now). VC-1 and H.264 were both much, much cheaper at the time.

Codec licensing fees are still not insignificant and are the basis of a lot of the audio codec STB wars (Dolby/DTS/AAC). Even on modern platforms there is still a lot of legacy MPEG-2. It's different in Win8 because end-users purchase the product, whereas STBs are given away for free and so a few dollars saved across millions of devices is worth saving, nobody is going to notice a few extra dollars on Win8 RRP.

[phate89]

I don't know when it was added, but one of the mirrors of x264.nl is http://x264.x265.net/

[mandarinka]

Because the guy who has that mirror booked the domain for future use by any FOSS x264-like HEVC encoder - it is explained if you go straight to x265.net.

[lucassp]

Here's something: https://bitbucket.org/multicoreware/x265/wiki/RoadMap

[Selur]

"Development of x265 began very recently (March 2013)" shouldn't this be March 2012 ?

[jkauff]

There's an article on Slashdot today about the release of a pre-alpha version of x265. It includes links to evaluations by Tom's Hardware and Extreme Tech.

http://tech.slashdot.org/story/13/07/23/164228/next-gen-video-encoding-x265-tackles-hevch265

[Guest]

Interesting. Thanks for the heads up!

[anonymlol]

Thanks for the link.

Here's a build: x265 23.07.2013 (x86).zip (https://mega.co.nz/#!fF51VYiD!VBnffARHirnKbDI7GrP9aAdKzEBU5Dl-7-BUjzChlwE)

[filler56789]

Thanks for the link.

Here's a build: x265 23.07.2013 (x86).zip (https://mega.co.nz/#!fF51VYiD!VBnffARHirnKbDI7GrP9aAdKzEBU5Dl-7-BUjzChlwE)

Your intention is good, but that URL does not work with Opera, nor with Internet Explorer 8.

[Bigmango]

Your intention is good, but that URL does not work with Opera, nor with Internet Explorer 8.

Link is working fine here with latest versions of Internet Explorer, Chrome, Firefox.

Seriously, who is using outdated browsers like IE 8 in 2013, and then posting on forums to complain about it?

Thanks for the links.

[mandarinka]

I saw some articles about x265 already, today. I guess the era of rapture has begun! :D

There is a piece written by Tom's hardware (http://www.tomshardware.com/reviews/x265-hevc-encoder,3565.html) and another one that is in czech language, so not much use unless you like google translate or something (link is here (http://www.cnews.cz/pristi-tyden-prijde-x265-oficialni-naslednik-enkoderu-x264-pro-format-h265) for those who understand that language.)

[xooyoozoo]

There's an article on Slashdot today about the release of a pre-alpha version of x265. It includes links to evaluations by Tom's Hardware and Extreme Tech.

http://tech.slashdot.org/story/13/07/23/164228/next-gen-video-encoding-x265-tackles-hevch265


From the Tom's Hardware article:

We could have used the --tune psnr switch to generate higher values, though this negatively affects subjective quality compared to the settings used here.

Which means that they didn't use tunings. By one line, they forwent any real analysis and trivialized their entire article, which can now be summarized as "why yes, this is a multithreaded HEVC encoder".

I forget how bewildering rookie codec comparisons can be.

Edit: Having issues compiling this on OSX 10.9 DP. Oh well, I'm gonna try the linked binary above on a Windows rig later.

[filler56789]

Link is working fine here with latest versions of Internet Explorer, Chrome, Firefox.

Seriously, who is using outdated browsers like IE 8 in 2013, and then posting on forums to complain about it?

Opera is NOT an outdated browser, and I did mention it.
But thanks for your pointless reply anyway.

[Selur]

from the "x265 Evaluation Guide 07-23-13.pdf":
SYSTEM REQUIREMENTS
Hardware: AVX capable CPU recommended
At least 8GB of RAM
Software: Win7/8 x86_64
Microsoft Visual C++ Redistributable Update 3assuming this is correct -> no x265 for me , since my i7 875k doesn't support AVX.

[mandarinka]

Oh, I missed that at first, but there is already an announcement (http://forum.doom9.org/showthread.php?p=1637971) in the news section of the forum.

from the "x265 Evaluation Guide 07-23-13.pdf":
assuming this is correct -> no x265 for me , since my i7 875k doesn't support AVX.

That's a recommendation - I'm pretty sure they won't explicitly require anything higher than SSE2 (SSSE3 at worst?).

[Guest]

Opera is NOT an outdated browser, and I did mention it.
But thanks for your pointless reply anyway. I'm not sure why you are trying to stir up trouble here, but if you continue there will be consequences. Please take any reponse to PM. Thank you.

[foxyshadis]

Wow, I completely missed that x265 was being commercially funded now, no wonder it's getting up to speed so quickly. The bleeding edge looks very promising, I just hope they can integrate Avisynth soon; at least they have Y4M, so you can use an ffmpeg intermediary instead of straight raw video.

[mandarinka]

I sort of got used to avs2yuv already (10-bit filtering, testing of VP9), so as long as that is supported, I guess it is relatively fine, input-wise.

[lainiwaku]

http://x265.org/

is it project from developer of x264 ??
or from the chinese guys project ??
https://code.google.com/p/x265/

[sneaker_ger]

is it project from developer of x264 ??
or from the chinese guys project ??

Neither. This seems to be from MulticoreWare as discussed a few posts above. Looks like many people want to benefit from x264's fame to promote their own project.

http://forum.doom9.org/showthread.php?p=1637971

/edit:
I stand corrected (see below).

[Dark Shikari]

MultiCoreWare's project is being made with the (very tentative) blessing of the x264 team. Unlike the others, as far as I know, it will actually be based on x264's source and algorithms and be a publicly developed open source project (e.g. something I could/might commit to). In other words, it exists as an open source project because I said "yes" to it :p (the alternative was a closed-source project unrelated to x264).

The intent is to link up with Videolan and friends, and there's already been quite a lot of back-room discussions, but it largely wasn't mentioned in the announcement because MCW didn't want to prematurely decide anything (they can only speak for themselves, not anyone else).

[smegolas]

is it project from developer of x264 ??
or from the chinese guys project ??
https://code.google.com/p/x265/

Neither. This seems to be from MulticoreWare as discussed a few posts above. Looks like many people want to benefit from x264's fame to promote their own project.

http://forum.doom9.org/showthread.php?p=1637971

Im pretty sure it is the Chinese guys project, and Multicoreware have gotten involved and/or made some code contributions.

[Sagittaire]

work here but it's really slow. Strongene_Lentoid_HEVC_Encoder work at ~1 fps on 1080p with C2D Q6600 at 2.4 Ghz.

[sneaker_ger]

Im pretty sure it is the Chinese guys project, and Multicoreware have gotten involved and/or made some code contributions.

I think lainiwaku wanted to know about x265.org, later mentioning "https://code.google.com/p/x265/" in the context of "the chinese guys project". "https://code.google.com/p/x265/" should indeed be from "the chinese guy" but I have not seen anything that lets me believe the two projects/sites are related to each other in any way (except being H.265 projects and sharing the same name). Then again I had no idea the MulticoreWare guys were in contact with the x264 and videolan teams...

/edit:
I stand corrected (see below).

[nevcairiel]

There are a bunch of commits from the "chinese guy" in the MCW x265 repository, so either they are working together, or they recycled some of his changes while keeping attribution.
However, it looks like they started with the HM encoder as a base, not the gcode x265

[sneaker_ger]

There are a bunch of commits from the "chinese guy" in the MCW x265 repository, so either they are working together, or they recycled some of his changes while keeping attribution.

Ah, I overlooked those. Would be great if we end up with a collaboration that results in a good free encoder.

[STaRGaZeR]

MultiCoreWare's project is being made with the (very tentative) blessing of the x264 team. Unlike the others, as far as I know, it will actually be based on x264's source and algorithms and be a publicly developed open source project (e.g. something I could/might commit to). In other words, it exists as an open source project because I said "yes" to it :p (the alternative was a closed-source project unrelated to x264).

The intent is to link up with Videolan and friends, and there's already been quite a lot of back-room discussions, but it largely wasn't mentioned in the announcement because MCW didn't want to prematurely decide anything (they can only speak for themselves, not anyone else).

So who's the project leader, or the one who decides what makes it to the repository and what not? Since there's a company and money involved...

[Dark Shikari]

It's kind of unclear at the moment; from what I recall they intend to add a few external committers and use a more x264-esque development model now that the code is released, but really, I suppose we'll basically wait and see what happens. Hence the tentative endorsement!

[dapperdan]

There are a bunch of commits from the "chinese guy" in the MCW x265 repository, so either they are working together, or they recycled some of his changes while keeping attribution.

Both projects (the google code one and the Multicoreware one) are using a dual GPL with a commercial licence option, so they can't use his changes unless they've come to some arrangement with him.

[turbojet]

It's nice to see the 3 parties trying to work together instead of fighting over the name 'x265'. It looks like Multicoreware has projects focused on opencl/cuda which brings some hope to achieving high quality, higher speed encoders in the future.

[x265_Project]

Hello everyone! I'm sorry for showing up late to the discussion, but I just created this account on Friday, and there is a 5 day waiting period before you can post messages.

As sborho (our lead developer) posted in the News section, MulticoreWare is excited to lead this project.

It is quite challenging to balance the needs and demands of our commercial customers (who are funding the development work) with the needs and desires of the open source community, but we are hopeful that we can manage the project in a way where everyone can benefit.

We will do our best to listen and learn, and answer questions to the extent possible.

Tom Vaughan
MulticoreWare

[Guest]

Welcome to the forum and thank you for your contributions!

[BadFrame]

It is quite challenging to balance the needs and demands of our commercial customers (who are funding the development work) with the needs and desires of the open source community, but we are hopeful that we can manage the project in a way where everyone can benefit.

We will do our best to listen and learn, and answer questions to the extent possible.

Here's hoping you will be able to provide this encoder under the same conditions as that of x264, fully open development and free to use according to an open source licence with additional licencing available for proprietary needs.

Thanks and good luck with the project, I will certainly enjoy following it.

[x265_Project]

Thank you for the warm welcome!

We are committed to offering x265 under both commercial and GPL 2 licenses, following the successful business model of x264. We will manage the open source side of the project in a way that is as fair and open as is reasonably possible.

MulticoreWare and developers have contributed to and managed a number of open source projects, and we are confident that the rest of the open source development community will appreciate the way that we manage this project. We welcome talented developers to join the project, and we will support them fully.

Tom
MulticoreWare

[xooyoozoo]

I got some time to test x265 on an old Windows Core 2 Duo using the ref pdf's settings (and bframes) and using a couple 1080p JCTVC test clips. There hasn't been any qualitative comments on x265, so I'll offer a few cursory ones.

Quality via MS-SSIM is roughly mid-teens percentage worse than anchor HM11 (parkscene, cactus). MS-SSIM quality versus VP9-cpu-0 on same clips (w/ 1 sec keyints) is strictly better. Subjective quality versus VP9-cpu-0 is distinctly better at QP32, mainly through temporal stability.

Speed on 2-thread x265 is comparable to single-threaded VP9-cpu-1 (https://groups.google.com/a/webmproject.org/d/msg/webm-discuss/bbMo00Gvops/-WyXm5dZQI4J), which is then comparable to multithreaded x264 placebo on this system.

All in all, I'm quite impressed by initial results. :)

Edit:

Ignoring the reference pdf's speed-focused switches will bring x265 almost right on top of anchor HM11 quality. On dual core, speed is now ~halfway between VP9-cpu-0 and cpu-1. Oh, and these were built with latest 8/2/13 commits.

[Sagittaire]

x265 is pre-alpha build. You can't use multithread encoding because quality will be very lower in this case. With best quality profil, x265 must have higher quality than HM11 ...

PS: Which decoder are you using? which muxer are you using? thank's

[xooyoozoo]

Well, I was purposefully vague because everything here is still quite transient. My fluffy definition of "almost right on top" quality-wise was low single-digit percents. According to the docs, that should more than account for WPP's slight quality cost (http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=2740) (<1% for 1080p).

I've had a good experience with GPAC for muxing/playing, but for the above, I've been using reference HM decoder, which also seems to match x265's internal yuv dump.

[gnaggnoyil]

I've just got MultiCoreWare's x265 source code and built a 8bit version successfully using i686-pc-mingw32 and x86_64-w64-mingw32 on win 7. However there is no "install" instuctions in the makefile generated by cmake. So what execuatables, libraries and headers should I copy in order to "install" it, I mean, to use the x265 library just like how x265.cpp use it? Or x265 just isn't planning to offer a library for other developers to use right now?

BTW: Why the file size of the x265 executable generated by mingw/gcc and MSVC differ so much? The former is about 4-5MB file size and the latter is only about 1.5MB file size...

[easyfab]

I think MSVC is shared ( you need Microsoft Visual C++ Redistributable Update 3 ) and MinGW is static.
Perhaps try to select STATIC_LINK_CRT in cmake to see the difference

[gnaggnoyil]

I think MSVC is shared ( you need Microsoft Visual C++ Redistributable Update 3 ) and MinGW is static.
Perhaps try to select STATIC_LINK_CRT in cmake to see the difference

I can make sure that crt is static linked using MSVC. STATIC_LINK_CRT is set true and the generated executable can run without Microsoft Visual C++ Redistributable.

And the executable is just 1.5MB file size.

https://photos-1.dropbox.com/t/0/AACr1e2PDITSI42j017RAFcF5eEWVrf7sVZ-ZURb-3QnpQ/12/18877564/png/2048x1536/3/1375729200/0/2/snapshot1.PNG/Il5CrnT8u--kX5iRI4-h_TOwDTJTyjOZUJIkA7r-_Uc

[Guest]

Isn't x265 GPL? If so you have to supply the source code as well, per GPL. Failure to comply will result in your posts being deleted. Also, no foreign languages in your signature. Thank you.

[nevcairiel]

He just created a vanilla build with a special flag on the build command line, how does that require sources? o.O

[gnaggnoyil]

Isn't x265 GPL? If so you have to supply the source code as well, per GPL. Failure to comply will result in your posts being deleted. Also, no foreign languages in your signature. Thank you.

sorry i didn't thought that it is a kind of "redistribution". i've uploaded a screenshot instead.

[foxyshadis]

sorry i didn't thought that it is a kind of "redistribution". i've uploaded a screenshot instead.

It is, but the GPL actually only requires "source code on request"; pointing to the exact git revision on bitbucket would satisfy the requirement, unless you applied any patches.

[roa]

Hi,
I made some tests for HEVC HM 9.0 and h.264 (ffmpeg).
For a video in CIF format, with a Gop size of 4, in lossy mode - 1bit/pixel I got the following results:
=> PSNR luma for h.264 = 30 dB
=> PSNR luma for HEVC = 31 dB
Does anyone have any idea? I think I should obtain much more better results with HEVC.
Thank you in advance

[x265_Project]

Hi,
I made some tests for HEVC HM 9.0 and h.264 (ffmpeg).
For a video in CIF format, with a Gop size of 4, in lossy mode - 1bit/pixel I got the following results:
=> PSNR luma for h.264 = 30 dB
=> PSNR luma for HEVC = 31 dB
Does anyone have any idea? I think I should obtain much more better results with HEVC.
Thank you in advance

I would use HM 10.1 or 11 for your tests. The trick to running the HM reference encoder is to create the right configuration file for your video input. In the HM distribution there is a cfg subfolder that contains standard configuration files. I would start with encoder_randomaccess_main.cfg. In this cfg folder there is a per_sequence subfolder that has the File I/O settings for each standard test sequence. You have to edit this section for your cfg file to match your input test video.

PSNR values will depend on the bit rate for each encoder, as well as the settings for all of the many decisions that encoders must make (run fast, or take your time and find the best possible result). PSNR values alone are meaningless. We have to look at PSNR vs bit rate, and at the same time, PSNR vs encoding speed. Of course, experts will also tell you that PSNR isn't the best measure of visual quality (and they're right)... but that's another topic.

By the way... we've posted a new Evaluator's Guide on the x265 repository... https://bitbucket.org/multicoreware/x265/downloads/x265%20Evaluators%20Guide%2008-12-13.pdf

Tom
MulticoreWare

[Sagittaire]

Possible someone make x265.exe build with last source?

thx.

[MasterNobody]

Possible someone make x265.exe build with last source?

thx.
x265+src.zip (http://www.sendspace.com/file/khd50p) version 0.3+355-23d8d29c5242 (rev 3512)

[Sagittaire]

x265+src.zip (http://www.sendspace.com/file/khd50p) version 0.3+355-23d8d29c5242 (rev 3512)

well http://www.sendspace.com/ don't work. It's really bad idea to use that for download. I download a lot of spyware. It's really ... big and beautifull shit ... ;-). Anyway thx.

[phate89]

well http://www.sendspace.com/ don't work. It's really bad idea to use that for download. I download a lot of spyware. It's really ... big and beautifull shit ... ;-). Anyway thx.
It is enough read well and avoid to download the file with their download manager and it works well..

[LigH]

Maybe MediaFire (http://www.mediafire.com/download/bqtj4jpdv06vy16/x265_r3512.zip) has less annoying and confusing ads. (Hope you don't mind the mirror, MasterNobody.)
__

P.S.: Did I miss them already being available, or are AviSynth compatible decoders (e.g. LAV / L-SMASH) "planned soon™"?

[nevcairiel]

ffmpeg/Libav have a decoder in the works, which still needs a lot of cleanup, but is otherwise functional .. it may appear somewhat "soon" in the source tree, an exact time plan is impossible to say of course.

[LigH]

Well, x265 can read raw YUV or Y4M only still, so testers will get used to its handling rather soon.

What are currently recommended filename extensions for the raw H.265/HEVC output?

[easyfab]

With the hevc decoder patch for libav, the raw extension are : "hevc,h265,265"
And yes the decoder seems to work well with x265. Hope HEVC file format in mp4 and mkv will be soon available.

[LigH]

The MP4Box in GPAC 0.5.1 Nightly Builds multiplexes HEVC into MP4. I just tested the Sintel trailer which took ~1:23h with defaults.

x265.exe sintel_trailer_1080.y4m -o sintel_trailer_1080.hevc
mp4box.exe -add sintel_trailer_1080.hevc#trackID=1:fps=24.0 -new sintel_trailer_1080_hevc.mp4

And its Osmo4 plays it ... well ... possibly not multi-threaded, it can hardly cope with FullHD resolution (1080p).

The default quantization of x265 (QP = 32) is too coarse. My result had ~360 kbps which is too little for FullHD; yet, it had a few surprisingly sharp details.

[easyfab]

Yes I know that GPAC can mux hevc in mp4 and there is also a Divx muxer for mkv and xhevc muxer for flv, but no real standard, if I remember correctly JEEB said that the HEVC file format is under certification procedure and the final draft is not available yet.

[xooyoozoo]

And its Osmo4 plays it ... well ... possibly not multi-threaded, it can hardly cope with FullHD resolution (1080p).

DivX has released a plugin (http://labs.divx.com/node/127923) for their web player if you want to try playing HEVC in your browser. You'd need to use their MKV mixer, and they claim a quad core i5 can do realtime 1080p decoding with their Tears of Steel clips.

I haven't tested it, but maybe their decoder could be more optimized.

The default quantization of x265 (QP = 32) is too coarse. My result had ~360 kbps which is too little for FullHD; yet, it had a few surprisingly sharp details.

Just remember that, by default, biprediction is currently turned off in x265, which makes bitrate to quality assessments a bit more difficult unless you're explicit interested in low-delay scenarios.

I imagine all the fades in the Sintel trailer would also benefit from turning on weighted prediction too, and all this is currently quite unoptimized and slow.

[JEEB]

What about MMT container:
http://en.wikipedia.org/wiki/MPEG_media_transport
?

Currently in an FCD ballot (http://lucia.itscj.ipsj.or.jp/standard/servlets/DocumentSearch?ID=112&sn=2300800101000000&sg=24&st=1&stp=1&m=1&m2=0) (nowadays called the DIS ballot (http://www.iso.org/iso/home/standards_development/resources-for-technical-work/stages_table.htm#s40), but the lucia system seems to be using the older terminology), which will be finished in October. After that there will be a two-month FDIS ballot with the final draft.

[LigH]

I played a bit more with options and got some buggy results, green and pink squares popping up now and then; I believe it is related to shortcut options?

x265.exe sintel_trailer_1080.y4m -o sintel_trailer_1080.hevc -q 20 -b 3 --weightp --weightbp --early-skip --fast-cbf

http://frupic.frubar.net/thumbs/30115.png (http://frupic.frubar.net/30115)

[filler56789]

I played a bit more with options and got some buggy results, green and pink squares popping up now and then; I believe it is related to shortcut options?

x265.exe sintel_trailer_1080.y4m -o sintel_trailer_1080.hevc -q 20 -b 3 --weightp --weightbp --early-skip --fast-cbf

-b N => currently this setting is problematic for the Lentoid DirectShow decoder; add to that the Wavefront Parallel Processing (which now is enabled by default), and the problems may get even worse.

[LigH]

It was played with GPAC 0.5.1 Nightlies' Osmo4. I doubt this one uses DS filters?

[filler56789]

So you can conclude the OpenHEVC decoder is not that good either :)

[x265_Project]

If you have an encoded bitstream that can't be decoded perfectly by a particular decoder, and you are wondering whether the encoded stream is compliant with the HEVC specifications or not, I suggest that you use the HM reference decoder to decode to YUV, then use YUVplayer to examine the decoded frames. This will answer your question (is it the encoder, or the decoder that is not working properly?) Of course, uncompressed YUV video requires a lot of storage space, so be sure that you limit the number of frames you are decoding.

Tom

[LigH]

Well, uncompressed YUV was required by the encoder too, as long as it has no AviSynth or pipe support. At least the input in Y4M format is a little advantage, saving a few CLI parameters.

I will tell you if the reference decoder restored correct or bugged frames, as soon as RawSource (http://forum.doom9.org/showthread.php?t=39798) got updated to support AviSynth 2.60 MT alpha 4 (same CACHE_MODE interface failure as MaskTools 2). This decoder, unfortunately, appears to output plain YUV only, not Y4M; or did I miss the required parameter?

[LigH]

Chikuzen released (http://forum.doom9.org/showthread.php?p=1641673#post1641673) a new build of RawSource.

Result: HM 11 decodes with the same error. So it may be the proof for an encoder issue.

http://frupic.frubar.net/thumbs/30186.png (http://frupic.frubar.net/shots/30186.png) — frame 44

Raw HEVC file (http://www.mediafire.com/?tzk9y3s6rngioxs) (~10 MB), x265 r3512, current command line options:

-q 20 -b 3 --weightp --weightbp --no-early-skip --no-fast-cbf --rdpenalty 1

[filler56789]

Thanks for testing and reporting :goodpost:

And yes, ooops, my guess was wrong :o

[ozok]

I've been writing a small GUI for x265.exe. You can download it from here (https://bitbucket.org/ozok/x265gui/downloads). It's not much but beats command line IMHO if you wan to run tests. It'll first convert source to yuv then feed this to x265.exe and later will mux this h265 stream with audio into mp4. Also, you can save created command lines to make things easier. Feedbacks are welcome, as always.

[LigH]

Version 0.3+504 by Vid01 (https://docs.google.com/file/d/0BwG6R5Qjd1f2X2JUTjJnN3Fsbm8/edit?usp=sharing) appears to be less stable. It crashes early (<50 frames). Due to a recommendation, I will discuss this also directly in the VideoHelp forum thread (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2262808&viewfull=1#post2262808).

[edison]

I've been writing a small GUI for x265.exe. You can download it from here (https://bitbucket.org/ozok/x265gui/downloads). It's not much but beats command line IMHO if you wan to run tests. It'll first convert source to yuv then feed this to x265.exe and later will mux this h265 stream with audio into mp4. Also, you can save created command lines to make things easier. Feedbacks are welcome, as always.

Does it support .avs as import ?

[ozok]

I didn't try it but I think it'll fail because it needs audio at last step even if you select not to encode audio. I'll release a fix for that asap.

[ozok]

I updated GUI to build 92. Now disabling audio should work. Downloads are here: https://bitbucket.org/ozok/x265gui/downloads

[xooyoozoo]

Just FYI, some days ago they switch the fixed GOP structure into alternating P/B frames. Maybe it's a half step in preparation for other things, and I'm really hoping to see intelligent/adaptive frame decisions soon. In the meantime, though, quality dropped quite a bit compared to the old HM-like random access structure.

[Marchand]

x265 [info]: HEVC encoder version 0.3+614-0e0a822fd344
x265 [info]: build info [Windows][GCC 4.8.1][32 bit] 8bpp

https://shared.com/pwb6xve8kg

[edison]

I updated GUI to build 92. Now disabling audio should work. Downloads are here: https://bitbucket.org/ozok/x265gui/downloads

I think you need to add some GPAC .dl files into the package :)

I have tried some 4K .mp4 file as input but no one works.

[turbojet]

I updated GUI to build 92. Now disabling audio should work. Downloads are here: https://bitbucket.org/ozok/x265gui/downloads

What about piping yuv to x265 instead of writing to disk?

[LigH]

Would be useful, indeed; but for now, x265 has neither pipe nor AviSynth support.

[wOxxOm]

Regarding piping: what about making an Y4M mod of AVFS (http://forum.doom9.org/showthread.php?t=133313) as a workaround?

[LigH]

Hooking the file system with another kind of frame server, instead of implementing already well implemented features into x265?

[wOxxOm]

well, what else can I suggest? half a year has passed and x265 has no such basic feature as pipe support, so obviously it's infinitely hard to implement :D

[phate89]

well, what else can I suggest? half a year has passed and x265 has no such basic feature as pipe support, so obviously it's infinitely hard to implement :D
Half a year? Are you trolling?

[wOxxOm]

Half a year? Are you trolling?

am I? https://bitbucket.org/multicoreware/x265/commits/all?page=127

[nevcairiel]

You do realize that the devs are much more likely to implement the actual video coding, instead of some silly input plugins? :p
I don't think they consider it really ready for real-world usage, so those input things don't matter yet.

[wOxxOm]

nevcairiel, well, that's *obviously* why a suggested Y4M mod of AVFS would be a plausible workaround for *now*

p.s. unless someone would make a patched x265 build similar to the well-known patched x264 builds...

[LoRd_MuldeR]

If it can read YUV files already, implementing "pipe support" (i.e. reading the YUV data from the STDIN rather than from a "physical" file) should be done with one line of code.

And then you get Avisynth or VapourSynth or FFmpeg input for free ;)

- FILE input = fopen(input_path, "rb");
+ FILE input = (strcmp(input_path, "-")) ? fopen(input_path, "rb") : stdin;

Okay, for Windows support you'd need one more line of code:
_setmode(_fileno(stdin), _O_BINARY);


BTW: Looks like there is Y4M support already:
https://bitbucket.org/multicoreware/x265/src/3ea029900ab3ee58ed6b16c5c5a0a89975ba8c03/source/input/input.cpp?at=default

[LigH]

Commit, MuldeR. :)

[filler56789]

Commit, MuldeR. :)

No.

Compile and test. IF test.status=successful,
THEN commit = yes Yes YES
endIF

;) :D

[LigH]

Due to the edit:

BTW: Looks like there is Y4M support already:

Yes, x265 can read Y4M, which is certainly better than reading raw YUV.

But only from a disk file, that's the drawback. Having e.g. ffmpeg pipe Y4M into x265 would be useful, but x265 would have to choose STDIN as input "file" when its name is exactly "-" (but you will know better than me what else may be necessary, depending on the OS, e.g. forcing binary file mode?).

[turbojet]

It's understandable the core devs are focusing on video coding and as long as they can test it with current input options it's good enough. From a user's view it's very difficult to test (special input, decoder, etc.) and progress seems stagnant although it's not. Usability of the encoder is the biggest roadblock atm, improving it by simply allowing more inputs might lead to libav/ffmpeg decoders which might lead to more pull requests coming in which may land x265 more coders. From the posts on Doom9 seems they welcome contributions and are looking for developers.

During x264's infancy it had many input options and decoder support very early on even if the video quality/speed wasn't up to xvid's at the time.

[x265_Project]

It's understandable the core devs are focusing on video coding and as long as they can test it with current input options it's good enough.

This is true... thanks for understanding. We're in the midst of making some very substantial changes to implement frame-level parallelism. We're getting there, but this is not quite done (although the results at this point are very encouraging). Testing is being done with standard YUV or Y4M files (uncompressed video frames) as input. That being said, we understand the desire for x265 to have pipe and AVIsynth support.


From a user's view it's very difficult to test (special input, decoder, etc.) and progress seems stagnant although it's not. Usability of the encoder is the biggest roadblock atm, improving it by simply allowing more inputs might lead to libav/ffmpeg decoders which might lead to more pull requests coming in which may land x265 more coders. From the posts on Doom9 seems they welcome contributions and are looking for developers.

During x264's infancy it had many input options and decoder support very early on even if the video quality/speed wasn't up to xvid's at the time.

As LoRd_MuldeR points out, the beauty of x265 being an open-source project is that anyone can contribute the improvements that they would like to see, but aren't seeing fast enough. We absolutely welcome contributions, and we are looking for developers to join the project.

Tom

[LigH]

I'd love to be able to contribute, but C / C++ don't belong to the list of programming languages I know good enough... :o

Anyway: :thanks: for being busy and research the future of video coding.

[turbojet]

Is Lord_Mulder's 'patch' sufficient?

[filler56789]

@ turbojet: Lord Mulder's post does NOT indicate which file(s) are to be modified,
so, strictly speaking, his suggestion cannot be defined as a *patch* :(

[LoRd_MuldeR]

Is Lord_Mulder's 'patch' sufficient?

This was not an actual patch, just a broad hint on how this stuff is done in general ;)

Actually, x265 uses C++ fstream's rather than classic FILE* pointers, so a slightly different (though equivalent) solution will be needed.

I would write a proper patch, but I'm about to leave for vacation...

[filler56789]

This was not an actual patch, just a broad hint on how this stuff is done in general ;)

Actually, x265 uses C++ fstream's rather than classic FILE* pointers, so a slightly different (though equivalent) solution will be needed.

I would write a proper patch, but I'm about to leave for vacation...

Are you still on vacation? :)

[filler56789]

well, what else can I suggest? half a year has passed and x265 has no such basic feature as pipe support, so obviously it's infinitely hard to implement :D

Overdue update: 7.4 months have passed since their "zeroth" commit:

Steve Borho 09fe406 commit JCT-VC HM source with cmake based build scripts 2013-03-07

( currently at the bottom of the page:
https://bitbucket.org/multicoreware/x265/commits/all?page=152 )

[benwaggoner]

Overdue update: 7.4 months have passed since their "zeroth" commit:
They are cranking HARD on improving image quality, and there's tons of x264 features to port over. I'd expect that "utility" features like this aren't going to get a lot of attention for a while yet.

[MoSal]

@filler56789

Note: I didn't test x265 myself yet.

You can have pipe support with all applications at a higher level if the application does not seek.

In *nix for example, you can use process substitution which is a feature provided by shells:


# Substitute dump_command with any command that outputs to stdout
x265 -o outfile <(dump_command)


If the application is dumb enough to rely on file extensions, you can use named pipes (FIFOs):


mkfifo dump.yuv
x265 -o outfile dump.yuv


On a 2nd shell:
dump_command > dump.yuv

However, If seeking is used on input files, neither this nor LoRd_MuldeR's patch will work.

[LigH]

Both may not be helpful for Windows users...

Well, it is for testers. Testers are expected to have some "pioneer attitude". ;)

A few short "standard trailers" (e.g. Blender movies) will be fine for first experiences. Some of these are even downloadable as Y4M, I believe?