x265 HEVC Encoder

[Selur]

@x265:

   --sar                         Sample Aspect Ratio, the ratio of width to height of an individual pixel.
                                 Choose from 0=Unspecified, 1=1:1("square"), 2=12:11, 3=10:11, 4=16:11,
                                 5=40:33, 6=24:11, 7=20:11, 8=32:11, 9=80:33, 10=18:11, 11=15:11,
                                 12=64:33, 13=160:99, 14=4:3, 15=3:2, 16=2:1. Default 0
   --extended-sar                Use a custom Sample Aspect Ratio,[WxH]

Why not handle this intern and use "--sar widthxheight Specify Sample Aspect Ratio" instead?
Exposing two options to set the sample aspect ratio seems like a bad move, which will only lead to confusion.

[LigH.de]

According to hints in the patch commits, version 0.8 is approaching "soon™"; but I keep getting confused about the meaning of the "stable" branch. Every once in a while, branches fork and get merged. Obviously, I am not used to team development techniques...

But as long as it makes sense to the developers, and the result usually works, it will be fine for me.

[x265]

According to hints in the patch commits, version 0.8 is approaching "soon™"; but I keep getting confused about the meaning of the "stable" branch. Every once in a while, branches fork and get merged. Obviously, I am not used to team development techniques...

But as long as it makes sense to the developers, and the result usually works, it will be fine for me.

I'll explain...
New development work (new features and optimizations) are done in the development branch (also known as the default branch or, if you get the latest commit in the default branch, this is known as the development tip). At the end of a development cycle, we stop committing new features or optimizations to the default branch (developers working on these things keep them in their own private source code repositories). We focus only on debugging and stabilizing the development version of x265. We do extensive testing every day, but we do even more extensive testing during the days leading up to a "tag". When we are satisfied that the development version is debugged and reliable enough, we declare a new milestone, and we apply a new tag. We should reach the 0.8 tag soon.

What does this mean for the average x265 user? Well, if you want to run a reliable build of x265, you should create your build from the stable branch. If you want to see how the latest changes affect x265, you should build and test from the default branch.

Tom

[LigH.de]

Thank you. In general, I can imagine, I just wonder about the amount of changes still arriving after a "merge with stable", so I probably have to understand that there will be several "stable points" between milestones.

Another issue I wonder about is the time of patch submissions. Are they not synced to e.g. GMT? They seem to have all local times, therefore e.g. Gopu (sounds indian?) seems to submit patches "in the future", as the extreme of out-of-order arrivals, according to the Hg Workbench.
__

P.S.:

He may have set up his timezone wrong. His patches report GMT - 8:00 h (which would be US west coast), but if he is in India, he will have GMT + 5:30 h.

[x265]

x265 0.8 is a regularly scheduled feature release

= New in 0.8 =

* 4:4:4 internal color space is now supported. Input pictures must also be 4:4:4, 8 or 10bit. We advise to disable weightp with 4:4:4. Note that since the HEVC Range Extensions are not finalized, this feature should be considered highly experimental. Our output streams may not be compliant with the final spec.

* Improved VBV. x265 will now do mid-frame QP adjustments in order to better meet the bit target. Further improvements will be in the next release (partial slice re-encode when bit budget is very tight).

* FPS is finally handled in a sane fashion. It may be configured as a rational number (numerator/denominator) or as a float. The frame rate is now signaled in the VPS header for use by the decoder.

* VUI signaling is now exposed in the x265_param structure and in the x265 CLI. The exact params and CLI options should be considered experimental at this point, and are liable to change.

* Near full ASM coverage of the 8bit build, and much more 10bit assembly than the previous release. All of the interpolation and intra primitives that were written with SIMD intrinsics have been replaced with assembly routines.

* Input pixel bit depth is now decoupled from the internal bit depth. An 8bpp build and a 16bpp build of x265 will both be able to encode 8bit or 10bit or 16bit raw video streams. The encoder will shift and mask pixels as necessary to get them to the internal depth.

* Motion compensated weight analysis. This will be further improved in the next release.

= CLI changes since 0.7 =

# Added #

--scenecut <integer>
-i/--min-keyint <integer>

--vui
--sar <int:int|int>
--overscan <string>
--videoformat <string>
--range <string>
--colorprim <string>
--transfer <string>
--colormatrix <string>
--chromaloc <integer>
--[no-]fieldseq
--[no-]framefieldinfo
--crop-rect <string>
--timinginfo
--nal-hrd
--bitstreamrestriction
--subpichrd

See CLI help for descriptions

# Replaced options, to sync with x264 #

--refresh <integer> is now --[no]open-gop --frame-skip <integer> is now --seek <integer> -i/--keyint <integer> is now -I/--keyint <integer> (short opt case change)


= Upcoming work =

The next release will focus on improving all of the recently added features, particularly VBV and adaptive quant, and focusing heavily on improving perceptive visual quality.

[Marchand]

Major changes in version 0.8 x265 ....

Thanks for the information and we look forward to the tests.

[Selur]

Improved VBV.
...
focusing heavily on improving perceptive visual quality.

nice, may be we 2pass encoding isn't that far away.

[LigH.de]

Time for a current Evaluator's Guide?

[Marchand]

Time for a current Evaluator's Guide?

x265 Evaluators Guide March 4 2014

[Selur]

since x265 didn't post a link, I assume they don't want/need feedback

[LigH.de]

He posted this one in the doom9 forum. And you know ... fastest feedback is in the mailing list.

[x265]

since x265 didn't post a link, I assume they don't want/need feedback

Selur,
As always, feedback and contributions are welcomed!

Tom

[Selur]

not a big fan of mailing lists (mainly increases spam), I prefer bug trackers and forums.

here are my first thoughts about the current guide:

--overscan Region of image that does not contain information is added to achieve certain resolution or aspect ratio
Values: undef (Default), show, crop.

--crop-rect Add bitstream-level cropping rectangle.
Values: left, top, right, bottom

Shouldn't overscan define what to do with the cropping rectangle?
If not, how to specify the resolution that is mentioned in the overscan description?

-m/--subme Amount of subpel refinement to perform
Range of values: an integer from 0 to 7 (0: least…..7: most)
Default: 2

any additional infos regarding naming/meaning behind values other than 0 and 7?

For general consistency:

--timinginfo Add timing information to the VUI
Values: 0 (Default) or 1
--nal-hrd Add signal HRD information [NOT IMPLEMENTED]
Values: 0 (Default) or 1
--bitstreamrestriction specifies whether that the bitstream restriction parameters for the CVS are present
Values: 0 (Default) or 1 [NOT IMPLEMENTED]
--subpichrd Add sub picture HRD parameters to the HRD
Values: 0 (Default) or 1 [NOT IMPLEMENTED]
Copyright

should be replaced with --[no]-nal-hrd, etc.

--log Logging level
Values : 0:ERROR; 1:WARNING; 2:INFO(Default); 3:DEBUG; 4:FULL
-1:NONE

--input-csp Source color space parameter, auto detected if Y4M;
Values: 1:”i420” (Default), or 3:”i444”[

--me Motion search method 0: dia; 1: hex (Default); 2: umh; 3: star; 4: full

confusing, not clear if a number or a string is required

--videoformat Specify video format, Explains what type analog video was before digitizing/encoding
Values: 0: undef, 1: component, 2: pal, 3: ntsc, 4: secam, 5: mac (Default)

shouldn't 'undef' be the default and not 'mac' ??

[x265]

not a big fan of mailing lists (mainly increases spam), I prefer bug trackers and forums.

Given the two options, our engineers prefer bug trackers. The signal to noise ratio is higher.

here are my first thoughts about the current guide:

--overscan Region of image that does not contain information is added to achieve certain resolution or aspect ratio
Values: undef (Default), show, crop.

--crop-rect Add bitstream-level cropping rectangle.
Values: left, top, right, bottom

Shouldn't overscan define what to do with the cropping rectangle?
If not, how to specify the resolution that is mentioned in the overscan description?

uhm yeah, --overscan does specify what the decoder should do with --crop-rect. The behavior is correct but the documentation is wrong.
We are patching the CLI help to:

    H0("   --crop-rect <string>          Add 'left,top,right,bottom'
to the bitstream-level cropping rectangle\n");
    H0("   --overscan <string>           Specify whether it is
appropriate for decoder to show cropped region: undef, show or crop.
Default undef\n");

-m/--subme Amount of subpel refinement to perform
Range of values: an integer from 0 to 7 (0: least…..7: most)
Default: 2

any additional infos regarding naming/meaning behind values other than 0 and 7?

It's too much detail for CLI help. Once we get electronic docs, the whole table can be spelled out.

I can add to the eval guide: larger values add more search offsets and more iterations.

For general consistency:

--timinginfo Add timing information to the VUI
Values: 0 (Default) or 1
--nal-hrd Add signal HRD information [NOT IMPLEMENTED]
Values: 0 (Default) or 1
--bitstreamrestriction specifies whether that the bitstream restriction parameters for the CVS are present
Values: 0 (Default) or 1 [NOT IMPLEMENTED]
--subpichrd Add sub picture HRD parameters to the HRD
Values: 0 (Default) or 1 [NOT IMPLEMENTED]
Copyright

should be replaced with --[no]-nal-hrd, etc.

agreed, those are inconsistencies in the doc.

Only --timinginfo is allowed by the CLI, and it takes no option because it is a bool option. We should add --no-timinginfo to be pedantic, but the default is false. The same applies to --bitstreamrestriction and --subpcihrd. They are bool flags that take no arguments and they default to false.

--nal-hrd docs are just wrong. There are two HRD CLI options:

--hrd (bool, like --timinginfo)
--nal-hrd <string> none, vbr or cbr. Default none

--log Logging level
Values : 0:ERROR; 1:WARNING; 2:INFO(Default); 3:DEBUG; 4:FULL
-1:NONE

--input-csp Source color space parameter, auto detected if Y4M;
Values: 1:”i420” (Default), or 3:”i444”[

--me Motion search method 0: dia; 1: hex (Default); 2: umh; 3: star; 4: full

confusing, not clear if a number or a string is required

--input-csp and --me and most of the VUI options support either.
--log will also accept either, once we commit a patch for this.

--videoformat Specify video format, Explains what type analog video was before digitizing/encoding
Values: 0: undef, 1: component, 2: pal, 3: ntsc, 4: secam, 5: mac (Default)

shouldn't 'undef' be the default and not 'mac' ??

Good catch. That's a bug in the doc. The CLI help says:

--videoformat <string> Specify video format from undef,
component, pal, ntsc, secam, mac. Default undef

[LigH.de]

"Am I right in assuming that" x265 is not yet able to encode interlaced material efficiently?
_

^ catch phrase especially in the german version of "What's My Line?" = "Was Bin Ich?"

[Selur]

@LigH: afaik HEVC doesn't support interlaced encoding at all , so it would be odd if x265 would

Video material to be encoded by HEVC is generally expected to be input as progressive scan imagery (either due to the source video originating in that format or resulting from deinterlacing prior to encoding). No explicit coding features are present in the HEVC design to support the use of interlaced scanning, as interlaced scanning is no longer used for displays and is becoming substantially less common for distribution.

source: http://iphome.hhi.de/wiegand/assets/pdfs/2012_12_IEEE-HEVC-Overview.pdf

[LigH.de]

Well, with the target of LCD monitors (both TV sets and PC monitors), it does indeed not make much sense.

But that also excludes many of the usual video test clips. Only 720p{double} and 1080p of e.g. the LDV set remain sensible.

[Selur]

But that also excludes many of the usual video test clips.

Yes, unless you simply deinterlace those clips beforehand.

Well, with the target of LCD monitors (both TV sets and PC monitors)

mobile devices (like mobiles and tablets) are also a huge part of that

[LigH.de]

I just encoded some clips from the LDV test set with x265 v0.8. It shows the large span of different material quite well. Each clip lasts only 10 seconds, but the results vary a lot in size with CRF encoding.

Especially "parkrun" is a quite nasty sample. Moving the camera in parallel to a runner in front of several trees creates a kind of "parallax" view which makes it very hard for the motion estimation to find matching vectors with little difference, so the clip will probably have quite a lot of intra coding.

In contrast, a simple panning along and zooming into a wall of "shields" is no big issue; B frames with motion estimation and maybe even global motion compensation will be very efficient here. So it had just about 2/7 the size.

This conclusion is certainly not limited to HEVC only.

[LigH.de]

Just uploaded some 4K samples. Playback is choppy on a Phenom-II X4 with MPC-HC 1.7.3.

[LigH.de]

Also uploaded a result of a speed benchmark with "insane" CLI options: --preset placebo -b 16 --ref 16 --crf 30 (720p50_parkrun_ter.insane.hevc.mp4; original material from the LDV test set)

Version 0.8+147 (GCC 4.8.2, Win64) of x265 ran at about 0.07 fps on a Phenom-II X4 945 (SSE2Fast, but neither SSE4 nor AVX).

[LigH.de]

@LigH: afaik HEVC doesn't support interlaced encoding at all , so it would be odd if x265 would

In this case, Steve is odd... — He seems to try it with an "experimental" patch.

[Selur]

I checked, it could encode a the fields separately and add some special flagging.
Encoding interlaced content is possible, HEVC just doesn't support it through special structures and encoding techniques like H.264 does.
-> Possible yes, but compression ratio will probably suffer quite a bit, so I wouldn't recommend it at all.
(not sure atm. if that special flagging will be properly supported by normal decoders)

[x265]

@LigH: afaik HEVC doesn't support interlaced encoding at all , so it would be odd if x265 would

Video material to be encoded by HEVC is generally expected to be input as progressive scan imagery (either due to the source video originating in that format or resulting from deinterlacing prior to encoding). No explicit coding features are present in the HEVC design to support the use of interlaced scanning, as interlaced scanning is no longer used for displays and is becoming substantially less common for distribution.

source: http://iphome.hhi.de/wiegand/assets/pdfs/2012_12_IEEE-HEVC-Overview.pdf

The above-referenced document goes on to say...

However, a metadata syntax has been provided in HEVC to allow an encoder to indicate that interlace-scanned video has been sent by coding each field (i.e., the even or odd numbered lines of each video frame) of interlaced video as a separate picture or that it has been sent by coding each interlaced frame as an HEVC coded picture. This provides an efficient method of coding interlaced video without burdening decoders with a need to support a special decoding process for it.

This is what we are supporting.

[Selur]

This is what we are supporting.

How can one indicate that the input is interlaced and not progressive, last time I checked there was no way to indicate this to x265,..

[x265]

I checked, it could encode a the fields separately and add some special flagging.
Encoding interlaced content is possible, HEVC just doesn't support it through special structures and encoding techniques like H.264 does.
-> Possible yes, but compression ratio will probably suffer quite a bit, so I wouldn't recommend it at all.
(not sure atm. if that special flagging will be properly supported by normal decoders)

Decoding is one thing, display is another. Any compliant HEVC decoder will have no trouble decoding this content. Displaying the content properly on a progressive-scan system (i.e.; any modern device or display) will require de-interlacing the decoded content to convert to progressive frames.

[x265]

This is what we are supporting.

How can one indicate that the input is interlaced and not progressive, last time I checked there was no way to indicate this to x265,..

Selur - It's not exposed yet. We're working on it.

[Selur]

Ah, okay sounded like it was already there.
Thanks for clearing that up.

[DarrellS]

Multicoreware better get on the stick cause Rovi/DivX has released an upgraded DivX265.exe encoder and the encode speeds are much higher than both their old encoder and the x265.exe encoder. My last encode was a 3200x1800 animation at 7 fps compared to the x265 encoder at a little over 2 fps on my Q6600 running Windows 7 with 4GB of memory.

It has a width limit of 4096 for 4k encodes. I'll try a 4k encode and report back on my results.

Here is the new DivX265.exe encoder...

DivX HEVC Encoder v1.2.24 (3-14-2014) http://download.divx.com/hevc/DivX265_1.2.24.exe

-aqo <1-5> Algorithm quality optimized for: 1:fastest speed 2:fast 3:balanced(*) 4:higher quality 5:highest quality.

Command line argument for Virtualdub external encoder...

-i - -s %(width)x%(height) -br 4000 -aqo 1 -o "%(tempvideofile)"

[Selur]

Just wondering have you tried to compare the results? (at nearly the same size)
At least for me, speed isn't as important as quality,...