x265 HEVC Encoder

[Placebo]

The x265 encoder is quite new and people are still working on it.
I want to contribute towards its development too.
The End Of Semester holidays are coming up on the corner, and I want to get familiar and contribute towards the dev of x265 and make the most of this vacation.
I want to gain some practical exposure towards dev like this before my grad studies are over in the next 2 years
There are many organizations/groups undertaking/implementing this codec, So I want to join one of them. I want to know if anyone can help me become a part of this dev or how do I start ??
I'm willing to volunteer any type of work , be it Testing new builds , encoding with different parameters, Bug tracking anything would do

I'm also an Android enthusiast and am writing codes for a few good applications with a group of programmers at my College. I also plan to work on bringing the x265 codec onto the Droid platform.


Right now I'm also writing a Paper on the trends of the video consumption for my small region. To elaborate I'm collecting data so as to what are the various types of videos people are dealing with especially on the internet in my locality.It has been almost 2 years since I started gathering data.

Any hints would be appreciated.
Thanks in advance.

[Atak_Snajpera]

Difference in quality between ultrafast and medium is HUGE!

--preset medium --bitrate 6000 --fps 50 --min-keyint 50 --keyint 500
https://mega.co.nz/#!xINzCRDJ!Kvv7GK9yy1UEP06Fh3a8FjBzs3DFF80P8Etq2RRDjnU

--preset ultrafast --bitrate 6000 --fps 50 --min-keyint 50 --keyint 500
https://mega.co.nz/#!cB8QnI5T!jR6DDFLgwjXkBc3Gr2U3YL33_PKPigNE778Rauoqh4c

[DarrellS]

I know this animated GIF is not accurate because it only supports 256 colors, but it still shows differences in detail between UltraFast and Medium presets. This animation is a 100% crop:

If I was just using ultrarfast preset but I'm not. I'm using qp 18 also. Here is my command line in Virtualdub...

--preset ultrafast --qp 18 --input-res %(width)x%(height) --fps %(fps) - -o "%(tempvideofile)"

Here are the log files for both ultrafast preset and ultrafast with qp 18.

[i] VideoEnc: yuv [info]: 1920x1080 fps 24000/1000 i420 unknown frame count
[i] VideoEnc: x265 [info]: HEVC encoder version 0.9+114-c630b0b393ee
[i] VideoEnc: x265 [info]: build info [Windows][GCC 4.6.3][64 bit] 8bpp
[i] VideoEnc: x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[i] VideoEnc: x265 [info]: WPP streams / pool / frames : 34 / 4 / 2
[i] VideoEnc: x265 [info]: Main profile, Level-4 (Main tier)
[i] VideoEnc: x265 [info]: CU size : 32
[i] VideoEnc: x265 [info]: Max RQT depth inter / intra : 1 / 1
[i] VideoEnc: x265 [info]: ME / range / subpel / merge : dia / 25 / 0 / 2
[i] VideoEnc: x265 [info]: Keyframe min / max / scenecut : 24 / 250 / 0
[i] VideoEnc: x265 [info]: Lookahead / bframes / badapt : 10 / 4 / 0
[i] VideoEnc: x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 0 / 0 / 1
[i] VideoEnc: x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 0.0 / 0
[i] VideoEnc: x265 [info]: tools: cfm esd rd=3 lft
[i] VideoEnc: encoded 88 frames in 12.70s (6.93 fps), 520.46 kb/s
[i] VideoEnc:
[i] VideoEnc: x265 [info]: frame I: 1 Avg QP:25.00 kb/s: 2208.96
[i] VideoEnc: x265 [info]: frame P: 18 Avg QP:25.50 kb/s: 1584.25
[i] VideoEnc: x265 [info]: frame B: 69 Avg QP:27.77 kb/s: 218.47
[i] VideoEnc: x265 [info]: global : 88 Avg QP:27.27 kb/s: 520.46
[i] VideoEnc: x265 [info]: consecutive B-frames: 5.3% 5.3% 0.0% 0.0% 89.5%
[i] Mux: mkvmerge v6.9.1 ('Blue Panther') 64bit built on Apr 18 2014 18:23:38
General
Unique ID : 210865812995477077849829611090891760706 (0x9EA34741EA9AE9AA8B608BA21417E442)
Complete name : F:\Temp 3\New Folder\Ready\test-01.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 239 KB
Duration : 3s 667ms
Overall bit rate : 535 Kbps
Encoded date : UTC 2014-04-26 17:51:24
Writing application : mkvmerge v6.9.1 ('Blue Panther') 64bit built on Apr 18 2014 18:23:38
Writing library : libebml v1.3.0 + libmatroska v1.4.1
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Codec ID : V_MPEGH/ISO/HEVC
Duration : 3s 667ms
Bit rate : 524 Kbps
Width : 1920 pixels
Height : 1080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 24.000 fps
Bits/(Pixel*Frame) : 0.011
Stream size : 235 KB (98%)
Default : Yes
Forced : No

[i] VideoEnc: yuv [info]: 1920x1080 fps 24000/1000 i420 unknown frame count
[i] VideoEnc: x265 [info]: HEVC encoder version 0.9+114-c630b0b393ee
[i] VideoEnc: x265 [info]: build info [Windows][GCC 4.6.3][64 bit] 8bpp
[i] VideoEnc: x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[i] VideoEnc: x265 [info]: WPP streams / pool / frames : 34 / 4 / 2
[i] VideoEnc: x265 [info]: Main profile, Level-4 (Main tier)
[i] VideoEnc: x265 [info]: CU size : 32
[i] VideoEnc: x265 [info]: Max RQT depth inter / intra : 1 / 1
[i] VideoEnc: x265 [info]: ME / range / subpel / merge : dia / 25 / 0 / 2
[i] VideoEnc: x265 [info]: Keyframe min / max / scenecut : 24 / 250 / 0
[i] VideoEnc: x265 [info]: Lookahead / bframes / badapt : 10 / 4 / 0
[i] VideoEnc: x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 0 / 0 / 1
[i] VideoEnc: x265 [info]: Rate Control / AQ-Strength / CUTree : CQP-18 / 0.0 / 0
[i] VideoEnc: x265 [info]: tools: cfm esd rd=3 lft
[i] VideoEnc: encoded 88 frames in 13.04s (6.75 fps), 1486.03 kb/s
[i] VideoEnc:
[i] VideoEnc: x265 [info]: frame I: 1 Avg QP:15.00 kb/s: 8706.62
[i] VideoEnc: x265 [info]: frame P: 18 Avg QP:18.00 kb/s: 4517.59
[i] VideoEnc: x265 [info]: frame B: 69 Avg QP:19.75 kb/s: 590.54
[i] VideoEnc: x265 [info]: global : 88 Avg QP:19.34 kb/s: 1486.03
[i] VideoEnc: x265 [info]: consecutive B-frames: 5.3% 5.3% 0.0% 0.0% 89.5%
[i] Mux: mkvmerge v6.9.1 ('Blue Panther') 64bit built on Apr 18 2014 18:23:38

Complete name : F:\Temp 3\New Folder\Ready\test-02.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 672 KB
Duration : 3s 667ms
Overall bit rate : 1500 Kbps
Encoded date : UTC 2014-04-26 17:56:52
Writing application : mkvmerge v6.9.1 ('Blue Panther') 64bit built on Apr 18 2014 18:23:38
Writing library : libebml v1.3.0 + libmatroska v1.4.1
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Codec ID : V_MPEGH/ISO/HEVC
Duration : 3s 667ms
Bit rate : 1470 Kbps
Width : 1920 pixels
Height : 1080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 24.000 fps
Bits/(Pixel*Frame) : 0.030
Stream size : 658 KiB (98%)
Default : Yes
Forced : No

[DarrellS]

Just using the straight medium preset on my q6600 pc, superfast preset with qp 18 is 5 times faster than medium preset and has a much higher bitrate.

[i] VideoEnc: yuv [info]: 1920x1080 fps 24000/1000 i420 unknown frame count
[i] VideoEnc: x265 [info]: HEVC encoder version 0.9+114-c630b0b393ee
[i] VideoEnc: x265 [info]: build info [Windows][GCC 4.6.3][64 bit] 8bpp
[i] VideoEnc: x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[i] VideoEnc: x265 [info]: WPP streams / pool / frames : 17 / 4 / 2
[i] VideoEnc: x265 [info]: Main profile, Level-4 (Main tier)
[i] VideoEnc: x265 [info]: CU size : 64
[i] VideoEnc: x265 [info]: Max RQT depth inter / intra : 1 / 1
[i] VideoEnc: x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
[i] VideoEnc: x265 [info]: Keyframe min / max / scenecut : 24 / 250 / 40
[i] VideoEnc: x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
[i] VideoEnc: x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
[i] VideoEnc: x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
[i] VideoEnc: x265 [info]: tools: rect amp rd=3 lft sao-lcu sign-hide

[i] VideoEnc: encoded 88 frames in 81.80s (1.08 fps), 367.44 kb/s
[i] VideoEnc:
[i] VideoEnc: x265 [info]: frame I: 1 Avg QP:24.34 kb/s: 2022.91
[i] VideoEnc: x265 [info]: frame P: 18 Avg QP:24.61 kb/s: 1248.15
[i] VideoEnc: x265 [info]: frame B: 69 Avg QP:28.83 kb/s: 113.69
[i] VideoEnc: x265 [info]: global : 88 Avg QP:27.92 kb/s: 367.44
[i] VideoEnc: x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
[i] VideoEnc: x265 [info]: consecutive B-frames: 5.3% 0.0% 5.3% 5.3% 84.2%
[i] Mux: mkvmerge v6.9.1 ('Blue Panther') 64bit built on Apr 18 2014 18:23:38

Complete name : F:\Temp 3\New Folder\Ready\test-05-M.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 171 KB
Duration : 3s 667ms
Overall bit rate : 382 Kbps
Encoded date : UTC 2014-04-26 18:43:37
Writing application : mkvmerge v6.9.1 ('Blue Panther') 64bit built on Apr 18 2014 18:23:38
Writing library : libebml v1.3.0 + libmatroska v1.4.1
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Codec ID : V_MPEGH/ISO/HEVC
Duration : 3s 667ms
Bit rate : 374 Kbps
Width : 1920 pixels
Height : 1080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 24.000 fps
Bits/(Pixel*Frame) : 0.008
Stream size : 167 KB (98%)
Default : Yes
Forced : No

[DarrellS]

Looks to me like either your CPU really is that much slower (which is doubt) or your problem might not be the encoder alone.

Yeah, I haven't been happy with Windows 7 since I installed it. Everything seems to be way slower than XP was. Googling led me to others having the same issue and others saying that Windows 7 is much faster at everything than XP.

I think I'll re-install Windows 7 here in a little bit. I just ran HD Tune Pro on my C:\ and the results were pathetic.

22.3 MB/s minimum, 59.1 MB/s maximum, 50.0 MB/s average and 131.3 MB/s burst rate. These numbers are at half as fast as the numbers that I got with XP. When I transfer files, I'm lucky if I can get 30 MB/s.

I'm tempted to just stick the XP drive back in instead of re-installing all my programs again.

[gonca]

have ti fix pdf layout

mod please delete this post

[gonca]

Comparison of x265 to x264 >>> bitrates, presets, crf, ssim

[racer-x]

@ DarrellS Thanks for that Virtualdub preset:
--preset ultrafast --qp 18 --input-res %(width)x%(height) --fps %(fps) - -o "%(tempvideofile)"

It is similar in quality and speed to:
--preset ultrafast --crf 18 --input-res %(width)x%(height) --fps %(fps) - -o "%(tempvideofile)"

Do you know what the difference is between qp and crf? If you don't mind the larger file size and need faster speed, then UltraFast @ crf 18 or qp 18 should be fine.

[Selur]

Do you know what the difference is between qp and crf?

one sets a constant quantizer, the other tries to archive a constant rate factor

[x265]

The x265 encoder is quite new and people are still working on it.
I want to contribute towards its development too.
The End Of Semester holidays are coming up on the corner, and I want to get familiar and contribute towards the dev of x265 and make the most of this vacation.
I want to gain some practical exposure towards dev like this before my grad studies are over in the next 2 years
There are many organizations/groups undertaking/implementing this codec, So I want to join one of them. I want to know if anyone can help me become a part of this dev or how do I start ??
I'm willing to volunteer any type of work , be it Testing new builds , encoding with different parameters, Bug tracking anything would do

I'm also an Android enthusiast and am writing codes for a few good applications with a group of programmers at my College. I also plan to work on bringing the x265 codec onto the Droid platform.


Right now I'm also writing a Paper on the trends of the video consumption for my small region. To elaborate I'm collecting data so as to what are the various types of videos people are dealing with especially on the internet in my locality.It has been almost 2 years since I started gathering data.

Any hints would be appreciated.
Thanks in advance.

Hi Placebo,
We would welcome your participation in the project. As you pointed out, there are a number of companies and organizations building HEVC encoders, but I think you'll find that none are as accessible, well-documented and mature as x265.

We've got a page set up that answers the question... How To Contribute to x265. Once you've cloned the repository, built x265, and familiarized yourself with how it works, have a chat with our lead developer through IRC or the x265-devel email list, to figure out what part of x265 you would like to work on.

[Placebo]

Hi Placebo,
We would welcome your participation in the project. As you pointed out, there are a number of companies and organizations building HEVC encoders, but I think you'll find that none are as accessible, well-documented and mature as x265.

We've got a page set up that answers the question... How To Contribute to x265. Once you've cloned the repository, built x265, and familiarized yourself with how it works, have a chat with our lead developer through IRC or the x265-devel email list, to figure out what part of x265 you would like to work on.

Thanks for replying,
Yes @x265 I have already built the latest version of x265 and I'll some time to get familiar with it.
I would let you know when I'm ready to start.
regards.

[Gravitator]

I wonder ... is it possible to apply for complex plots 10bit lattice or grain for lifting qualities - as the transfer of useful noise

Yes you can - various dithering techniques or grain application - but that's usually not the job of the encoder

Hi!
1. Completely replace the 8-bit by 10-bit block;
2. Recovery - give 10bit pixels and distribute them to 8 bit darkest part (hybrid);
3. Approximate emulation - noise analysis and transmission of information for filter (example MadVR will use it for a more accurate noise generation - take from the stream HEVC).

[Selur]

@x265:
Hmm,....

Merge with default (code freeze for 1.0)

Quelle: https://bitbucket.org/multicoreware/x265/commits/c6ca14a4f2faff3d305f3ab2c4f7736693f54fbd
+

Our focus for the near future remains on visual quality and rate control improvements.

Quelle: https://forum.videohelp.com/threads/360069-x265-HEVC-Encoder?p=2313336&viewfull=1#post2313336
+
Looking at the changelog since April, I'm wondering: "Did the focus change?"
All the commits seems more like bugfixes and cleanups not really anything related to 'visual quality and rate control improvements', or am I missing something?

Cu Selur

[x265]

@x265:
Hmm,....

Merge with default (code freeze for 1.0)

Quelle: https://bitbucket.org/multicoreware/x265/commits/c6ca14a4f2faff3d305f3ab2c4f7736693f54fbd
+

Our focus for the near future remains on visual quality and rate control improvements.

Quelle: https://forum.videohelp.com/threads/360069-x265-HEVC-Encoder?p=2313336&viewfull=1#post2313336
+
Looking at the changelog since April, I'm wondering: "Did the focus change?"
All the commits seems more like bugfixes and cleanups not really anything related to 'visual quality and rate control improvements', or am I missing something?

Cu Selur

No, you didn't miss anything. Visual quality and rate control are our primary focus at the moment. Visual quality improvements can sometimes come in the form of bug fixes. Some bugs may introduce very small errors that aren't immediately obvious, but these errors can accumulate to reduce the quality of the overall result. Also, it doesn't make sense to optimize an algorithm if it has bugs (you're chasing bad data). So, a thorough debugging of all functions is an important part of the visual quality improvement process.

[gonwk]

Hi folks,

A Q from a Total Newbie ... is X265 playable on Standalone TV Media Players ... like WDTV, Netgear, etc.?

Thanks,

G!

[Selur]

atm. there's no standalone player which supports hevc (older players are all to slow or simple can't decode it)

[LigH.de]

@ gonwk:

There are UltraHD TV sets which support it (e.g. by LG). Just published on technology fairs. I doubt you will already afford them easily. Furthermore, hands off LG Smart TVs, they belong to those which spy on you and tell which channel you are watching when, or even the file names of the movie files you watch, while they are connected to the internet.
__

@ Selur:

I don't mind a priority towards fixing bugs. I know projects where implementing new features is preferred over bugfixing, and they are complained a lot.

[Selur]

@LigH: I to do not mind them fixing bugs, but I would have hoped for more obvious quality improvements and since, due to the code freeze, quality won't change it seems like it will stay as it is atm. till after 1.0

[x265]

@LigH: I to do not mind them fixing bugs, but I would have hoped for more obvious quality improvements and since, due to the code freeze, quality won't change it seems like it will stay as it is atm. till after 1.0

(with apologies to Paul Masson wines)... We will commit no patch before its time.

There are a number of improvements in development, but each "improvement" has to be thoroughly tested to make sure it is at least one step forward and no steps back. We're certainly not going to stop or slow the pace of development when we reach version 1.0.

[gonwk]

Hi Selur & LigH.de,

Thanks for your replies.

@ LigH.de ... you just sold me on not messing with LG TVs ... sounds they are copying gooogle's idea of Spying on everything you do. And you are right I most likely can't afford it anyway ... and I am still on Panasonic 36 inch Tube Type TV ... so u r right

G!

[Cornucopia]

Don't get yourself worked up. The turmoil that ensued when the public found out about the "spying" made LG backtrack and update their firmware yet again to where you as a user can manually enable/disable content tracking in the setup.

At least internet furor has some uses.

I know, I have an LG TV. It didn't have that tracking, then it did (with a firmware update), then it had a new update, and I disabled it. Like most pushy businesses, though, it DEFAULTS to being on.

Don't skip buying LGs on that account. Base your choice on quality (and there, I'm VERY satisfied with my LG for its price).

Scott

[El Heggunte]

1.0 is «officially» out

x265 1.0 is a regularly scheduled feature release

The only significance to the "1.0" tag is that this is our tenth tagged
release.

There were many bugs fixed since the 0.9 tag, particularly in rate
control and Main10 mode decision. There have been a couple of minor
performance improvements.

= Feature changes =

* Experimental support for 4:2:2
* improved profile and level detection
* imported checkasm-a.asm from x264 and fixed the asm bugs it exposed
* lookahead will use a worker thread when beneficial
* Many more motion candidate vectors are passed to motion estimation
* Lambda table improvements for better bitrate response at low QP

= API changes =

* added param.bEnableAccessUnitDelimiters
* removed param.vui.bEnableVuiParametersPresentFlag (now implied)
* removed param.vui.bEnableAspectRatioIdc (now implied)
* removed param.vui.bEnableVuiTimingInfoPresentFlag (always enabled)

= CLI changes =

--aud was added
--vui was removed
--timinginfo was removed (it is always enabled)

Our online documentation is steadily improving. I hope to add more
and more content over the coming weeks. http://x265.readthedocs.org/

Development is still focused on finding and fixing coding bugs,
improving rate control, and improving performance (in roughly that
order)

Regards,

--
Steve Borho

[LigH.de]

@ Cornucopia:

Still sending statistics while the possibly responsible menu option was "off" may have been a bug. Or not. Who knows. Implementing this feature was a bad choice. We sell our privacy for a discount. "Do you have a payback card?"...

In general, I agree that LG can produce good quality for a fair price. But if I buy a device, I'll try to get one that does its main job reliably. The more secondary features, the less reliable the primary may be. And IMHO, a TV set doesn't really need internet connection. It may be convenient to have all features in one device, but if only one feature fails, the whole device needs to be repaired or exchanged. And you know, modern devices are not made for repairs anymore.

[LigH.de]

I uploaded some 2160p clips (encoded with preset slow; any slower would have been a severe waste of time with my hardware).

[deadrats]

I uploaded some 2160p clips (encoded with preset slow; any slower would have been a severe waste of time with my hardware).

where exactly did you upload these? and do you have a link for the source as a comparison point. also what type of hardware do you have that allows you to encode 2160p x265 preset slow in anything remotely resembling a reasonable amount of time.

[LigH.de]

As usual, my MediaFire HEVC folder (linked again about monthly).

Source are some Y4M files downloaded from Derf's collection in the Xiph media archive.

The best CPU I can use with a 64 bit Windows 7 is an AMD Phenom-II X6 1045 (average speed: 0.06-0.09 fps). The current intel CPUs are just too expensive. An AMD FX-8K(+) would be a usable compromise; A8(+) are more modern but have too few cores.

[El Heggunte]

For the record:

x265 1.0+74 still produces strong artifices (SIC) when Psy-RD is enabled.

Binary (vanilla MSVC 2013 build):
http://www.mediafire.com/download/uops57uebg5pcbq/x265.win-x64-8bit.2014-05-19.rar

Command:

x265.exe --preset veryslow --psy-rd 1.0 -o psytest.hevc foreman_cif.y4m

Result:
http://www.mediafire.com/download/n379fbcl74rr7dr/psytest.2014-05-19.rar

[gonca]

LigH.de
If you want I can use my computer to do the encodes

[Selur]

@El Heggunte: tried to reproduce this with my own MinGW build, but couldn't -> Have you also tried to reproduce this this with MinGW builds?

[El Heggunte]

@Selur: well-spotted, me neither could reproduce the "strong artifacts" gotten by Lord Mulder

Possibly it's an MSVC-specific issue, then,