x265 HEVC Encoder

[benwaggoner]

I haven't specifically tested it but encoding with 10 bit is probably able to prevent most of it. Simply use a high-bitdepth build of x265, they will use 10 bit encoding by default.
x265 has a pretty good built in dithering mode as well, so if you need to encode at 8-bit from a 10-bit source, that's also an option.

Also, HEVC in general introduces less banding than H.264 does, so as long as you have source that's not banded in 8-bit, you may be pleasantly surprised by the results.

[Motenai Yoda]

Also, HEVC in general introduces less banding than H.264 does, so as long as you have source that's not banded in 8-bit, you may be pleasantly surprised by the results.
Well actually in a sensible number of times H.264 or HEVC doesn't "introduce" banding, but remove/reduce the slight dithering/noise that hide it. On 10bit encoding this dither/noise will be more often reduced like a some sort of gradient, that will be re-dithered at 8bit by decoders or renders.

[sneaker_ger]

Also, HEVC in general introduces less banding than H.264 does, so as long as you have source that's not banded in 8-bit, you may be pleasantly surprised by the results.

I did a test with low bitrates which show that x265 suffers from 8 bit as badly as x264, at least for low bitrates.
http://forum.doom9.org/showthread.php?p=1691801#post1691801

Open questions:
1. Would this be the same at higher bitrates?
2. Does x265 use the HEVC tools against banding?
http://forum.doom9.org/showthread.php?p=1614299#post1614299

[EndlessD]

I would also like to get access to some good sample anime content. SFW only please. Can you point me to some good examples?

Thanks,
Tom

On a side note:
Not every Anime is mastered in the same size and every release is different in terms of quality. If we are talking Japanese Animes, the Japanese BDs usually have the highest quality with a video-bitrate of ~35 Mbit/s, Western releases are most of the time at 15~25 Mbit/s. For DVDs the Japanese release is also the highest quality, most of the time at 9800 Kbit/s and Western releases fluctuate at normal DVD bitrates.
For Western or Korean Anime, I have no idea.

In terms of mastering size and quality they can be split in the following categories:

film content taken to DVD/BD (sometimes remastered)
SD mastered in 480p or smaller on DVD (pre HD time)
SD remasters on DVD (higher quality than the first DVD release)
SD remastered to 720~1080p achieved with filtering on BD
SD remastered in 540p/720p rescaled to 1080p on BD
SD remasters rescaled for DVD release (includes remasters achieved with filtering and normal ones)
HD mastered in ~720p rescaled to 1080p on BD (most common these days)
HD mastered in >720p but <1080p rescaled to 1080p on BD
HD mastered in 1080p on BD (still very rare these days)
HD rescaled to SD for the DVD release (this includes all HD categories)

I could provide samples for every category except the "film content" and ">720p but <1080p" or can provide some titles for each category.

[Darius510]

So I'm experimenting converting some blu-rays to h265. Ideally I'd like to maintain the same perceptual quality, without going overboard wasting bits accurately capturing what's merely a compression artifact from the original source. Something like a 18-16 CRF does a pretty good job, but sometimes the encoded video is even larger than the source!

Would using 2-pass ABR be better in this case? For example, setting the x265 bitrate at 60% of the source's bitrate for h264, 40% for vc1, and 25% for mpeg 2? Are there any advantages to encoding in 10-bit, even though the source is 8-bit? Would it decrease efficiency by encoding something that doesnt exist, or increase efficiency by giving x265 a wider palette of colors to work with? It's my understanding h264 has built in deblocking, does this mean I should use handbrake's deblocking filter during encoding, or does x265 take care of that automatically? What about the psychovisual options?

[sneaker_ger]

Would using 2-pass ABR be better in this case?
No, CRF and 2pass have about the same quality at the same bitrate. 2pass is only useful when you want to achieve a specfic bitrate/filesize instead of chooding a quality without knowing filesize.

For example, setting the x265 bitrate at 60% of the source's bitrate for h264, 40% for vc1, and 25% for mpeg 2?
x265 does not know about the original source format and Blu-Ray has so much bitrate that even MPEG-2 looks transparent.

Choose a CRF that you are happy with. Also, compare to x264. At high bitrates it's often better than x265 while being much faster and more compatible.

Are there any advantages to encoding in 10-bit, even though the source is 8-bit?
Yes, the higher internal precision increases efficiency.
See an example I just made:
http://forum.doom9.org/showthread.php?p=1691801#post1691801

It's my understanding h264 has built in deblocking, does this mean I should use handbrake's deblocking filter during encoding, or does x265 take care of that automatically?
H.264 and H.265 use in-loop deblocking, it's not meant to fix source files with blocking problems, only to prevent additional blocking during the encoding.

What about the psychovisual options?
They are still experimental but some claim good results for it.
These are listed as "typical value[s]":
--psy-rd 1.0 --psy-rdoq 1.0

[Zainian]

I would also like to get access to some good sample anime content. SFW only please. Can you point me to some good examples?


How about Big Buck Bunny? It's licensed under Creative Commons and has a 4K release: http://bbb3d.renderfarming.net/download.html

Okay, technically it's not anime produced in Japan, but it is still animation no?

[sneaker_ger]

They are probably talking about drawn/cartoon animation. CGI is a different matter.

[Darius510]

No, CRF and 2pass have about the same quality at the same bitrate. 2pass is only useful when you want to achieve a specfic bitrate/filesize instead of chooding a quality without knowing filesize.

x265 does not know about the original source format and Blu-Ray has so much bitrate that even MPEG-2 looks transparent.

Choose a CRF that you are happy with. Also, compare to x264. At high bitrates it's often better than x265 while being much faster and more compatible.

Well, I'm mostly just trying to save as much space as possible. I'm just trying to leverage the efficiency gains in h265 in my rips...CRF doesn't seem like the right tool for the job, when the input quality is so variable. For instance, with one source (LOTR), CRF 17 will compress a 35GB h264 file down to 6GB. With another (planet earth), it will compress a 8GB vc1 file down to 6GB. And it'll expand a 1GB mpeg2 source from a DVD to 1.5GB. That doesn't make any sense.

Maybe there's some flaw in my thinking, but knowing the relative efficiencies of each codec, shouldn't I be able to give h265 "enough" bits to reach the same relative quality? With 2-pass helping to distribute those bits appropriately over the whole file? Obviously it's not going to be perfect since I'm transcoding rather than working from the uncompressed master.

Yes, the higher internal precision increases efficiency.
See an example I just made:
http://forum.doom9.org/showthread.php?p=1691801#post1691801

How does one enable 10-bit precision? Just choose the Main10 profile? Also, if this is such an easy win, why isnt it on by default?

H.264 and H.265 use in-loop deblocking, it's not meant to fix source files with blocking problems, only to prevent additional blocking during the encoding.

So the handbrake deblocking is unnecessary, correct?

They are still experimental but some claim good results for it.
These are listed as "typical value[s]":
--psy-rd 1.0 --psy-rdoq 1.0

I've noticed they don't work with an rd of less than 4, which only slow and above have...and they are SLOW. Is it fine to manually just set rd to 4 on medium/fast, or does it need the other parameters of the slower presets to work properly?

[sneaker_ger]

CRF doesn't seem like the right tool for the job, when the input quality is so variable. For instance, with one source (LOTR), CRF 17 will compress a 35GB h264 file down to 6GB. With another (planet earth), it will compress a 8GB vc1 file down to 6GB. And it'll expand a 1GB mpeg2 source from a DVD to 1.5GB. That doesn't make any sense.
x265 does not know how big your source files were or what codec they used. It uses uncompressed video data as input. If the movie is complex (e.g. lots of action, cuts, grain) it will use a lot of bitrate (compared to a different movie at the same CRF). That's the reason as to why the output can be bigger than your source files.

How does one enable 10-bit precision? Just choose the Main10 profile?
Just use a high-bitdepth build. No additional settings are required. Check the log ("internal precision: 10") or MediaInfo to confirm it was done right.

Also, if this is such an easy win, why isnt it on by default?
Compatibility, not every decoder might be able to decode 10 bit HEVC. (+ maybe speed)

So the handbrake deblocking is unnecessary, correct?
If your source has blocking the handbrake filter might be useful. It the source has no blocking you don't need it.

Well, I'm mostly just trying to save as much space as possible. I'm just trying to leverage the efficiency gains in h265 in my rips
[...]
I've noticed they don't work with an rd of less than 4, which only slow and above have...and they are SLOW.
I really suggest you compare x264 to x265 yourself at the same bitrate. x265 is still very young, just because it uses a new video standard does not necessarily mean it always achieves better quality than the older x264 does.

[Darius510]

x265 does not know how big your source files were or what codec they used. It uses uncompressed video data as input. If the movie is complex (e.g. lots of action, cuts, grain) it will use a lot of bitrate (compared to a different movie at the same CRF). That's the reason as to why the output can be bigger than your source files.

Right, but I do...I can just check the source for it's bitrate and codec. Presumably the source has it's bits relatively distributed in the same way - more action = more bitrate.

The problem is that when its treating the input as if it's uncompressed, it can't tell a compression artifact from "real" detail. But regardless, given a fixed file size, all these codecs are going to distribute bits relatively the same way. So areas that are poorly compressed in one codec generally would be poorly compressed in another.

I've tested x264 vs x265 quite a bit, and even at the relatively high bitrates I'm encoding, given the same bitrate, there's no question that x265 comes out ahead every time.

[LigH]

It doesn't matter much whether you check its (no apostroph) bitrate if the video was once compressed with a lossy video compression technique, because the reconstructed video will not be the same as the original video. It will contain differences: compression artefacts. Another attempt to encode this output with a lossy compression technique may have to spend more bitrate for trying to maintain these compression artefacts than it would need to encode the really original video.

Hence, always prefer lossless material as common video source to compare different lossy compression codecs. Or at least use sources compressed with magnitudes of finer quantization than the ones you want to test (if you are about to compare bitrates or quality levels similar to CRF values >20, a source compressed with CRF <10 will possibly have no recognizable artefacts, relatively).

[sneaker_ger]

Right, but I do...I can just check the source for it's bitrate and codec. Presumably the source has it's bits relatively distributed in the same way - more action = more bitrate.
That presumption doesn't always hold true. I can encode the same video with --bitrate 1000 or --bitrate 50000. It does not tell you anything about the video complexity at all.
More examples:
- TV stream often use the constant bitrate assigned to them on e.g. the satellite. Complexity does not matter.
- On a Blu-Ray or DVD you might always try to fill the disc up completely. There is no reason to leave free space even for simple sources.

[Darius510]

It doesn't matter much whether you check its (no apostroph) bitrate if the video was once compressed with a lossy video compression technique, because the reconstructed video will not be the same as the original video. It will contain differences: compression artefacts. Another attempt to encode this output with a lossy compression technique may have to spend more bitrate for trying to maintain these compression artefacts than it would need to encode the really original video.

Hence, always prefer lossless material as common video source to compare different lossy compression codecs. Or at least use sources compressed with magnitudes of finer quantization than the ones you want to test (if you are about to compare bitrates or quality levels similar to CRF values >20, a source compressed with CRF <10 will possibly have no recognizable artefacts, relatively).

Definitely, but I simply don't have the uncompressed masters of studio films. Basically, I'm trying to solve a simple problem - I want to back up my blu-rays, and I don't have the space to store all the pure rips. I want to achieve near blu-ray quality at a smaller size by leveraging h265 instead of the less advanced codecs. Compatibility isn't an issue for me.

So I'm trying to figure out what's the best way to go about that, without wasting bits on perfectly reconstructing compression artefacts (that are barely visible anyway in fast motion scenes). Using CRF gives me unpredictable file sizes that probably waste too much bitrate on those artefacts...but would ABR really be any better about that?

[Darius510]

- On a Blu-Ray or DVD you might always try to fill the disc up completely. There is no reason to leave free space even for simple sources.

That's what I'd think too, but there is a huge variability...I've got single layer rips that range from 16GB to 24GB, dual layer rips that range from 25GB to 40GB. I'd think they'd want to use all the available space too, but that doesn't seem to be the case, even accounting for special features.

[x265_Project]

Definitely, but I simply don't have the uncompressed masters of studio films. Basically, I'm trying to solve a simple problem - I want to back up my blu-rays, and I don't have the space to store all the pure rips. I want to achieve near blu-ray quality at a smaller size by leveraging h265 instead of the less advanced codecs. Compatibility isn't an issue for me.

So I'm trying to figure out what's the best way to go about that, without wasting bits on perfectly reconstructing compression artefacts (that are barely visible anyway in fast motion scenes). Using CRF gives me unpredictable file sizes that probably waste too much bitrate on those artefacts...but would ABR really be any better about that?
Use ABR with 2 pass encoding. This will give you the highest possible quality at the bit rate you want.

[vivan]

Use ABR with 2 pass encoding. This will give you the highest possible quality at the bit rate you want.But he doesn't know what bitrate he wants!

[x265_Project]

But he doesn't know what bitrate he wants!
Well, yes... some experimentation may be needed. Darius510 just needs to figure out what percentage he wants to shrink his videos by. This use-case is perfect for H.265. Darius510 should be able to reduce the size of his high quality H.264 videos by 2x without a significant loss of quality, but he may be OK using an even higher shrink factor, depending on his priorities (smaller files, or highest possible quality). Use MediaInfo to determine the current bit rate of a video, then divide by the shrink X factor to determine the x265 bitrate setting. I would start with 2X, but you might even want to reduce your files by 3X or 4X.

[LigH]

If you don't know the target bitrate, but instead want to ensure a limited loss of quality, use CRF.

[xooyoozoo]

libvpx has a constrained-quality mode. It is a 2-pass encode where you set the maximum quality, so that any higher is wasting bits, and the suggested average bitrate, which is less strict than most 2pass modes. The libvpx encoder aims for the suggested bitrate unless local quality exceeds the previously set maxvalue. Then, quality is clamped, and bitrate can be lowered. If enough of a video is up against the quality "wall", then the total bitrate can be dramatically lower than the user-input bitrate value. IIRC, this is what Youtube uses for its WebM streams.

An ideal x265-analouge would be 2-pass with suggested bitrate, plus user-input min-crf (to not waste bits on easy clips), plus max-local-bitrate (to not waste bits on temporary complex parts; Main L5.0's vbv is probably enough for most 1080p videos).

The individual pieces seem to already exist in x265's cli, but I'm not sure if they can be combined and work as described above.

[LigH]

A reliable VBV control should achieve similar results. Just a bit more indirectly.

[Darius510]

Well, yes... some experimentation may be needed. Darius510 just needs to figure out what percentage he wants to shrink his videos by. This use-case is perfect for H.265. Darius510 should be able to reduce the size of his high quality H.264 videos by 2x without a significant loss of quality, but he may be OK using an even higher shrink factor, depending on his priorities (smaller files, or highest possible quality). Use MediaInfo to determine the current bit rate of a video, then divide by the shrink X factor to determine the x265 bitrate setting. I would start with 2X, but you might even want to reduce your files by 3X or 4X.


I've been having good results with 2X so far, honestly I'd be lying if I said I could see a difference without zooming way in and comparing side by side. 3x/4x is still quite good, but I'd prefer to preserve as much detail as possible.

Should I be taking the source codec into account though? I can see it both ways...h264 is obviously going to look way better than mpeg2 at a given bitrate, but where it falls apart tends to be very noisy instead of blurry. That's probably going to be even more demanding to transcode, not less.

[foxyshadis]

I've been having good results with 2X so far, honestly I'd be lying if I said I could see a difference without zooming way in and comparing side by side. 3x/4x is still quite good, but I'd prefer to preserve as much detail as possible.

Should I be taking the source codec into account though? I can see it both ways...h264 is obviously going to look way better than mpeg2 at a given bitrate, but where it falls apart tends to be very noisy instead of blurry. That's probably going to be even more demanding to transcode, not less.

You need to manually spot-check your discs' action scenes to see whether they're good or all screwed up. x265 certainly can't do this for you. For MPEG-2 video, there are some good quant-checkers out there, so you can quickly see if the quant is too high throughout the movie (quant has more correlation to quality in MPEG-2 than in newer codecs), then spot-check only the ones with bad numbers.

If a Blu-Ray is so small that a crf 18 is larger than the source, consider keeping the source. If you'd rather leverage the codec, then get rid of the crappy encode artifacts with pre-filtering (an --nr 100 might also help) and/or reduce resolution. Avisynth and ffmpeg have lots of ways you can filter, from lightning fast to slower than molasses. Personally, there's very little point to re-encoding instead of merely archiving if you're not going to make the video look better in the meantime. (If you make it look good enough, then maybe a little extra bitrate isn't unwarranted?) Otherwise, just raise the crf, because garbage in->garbage out, don't waste bits on it.

Are you certain you're not encoding interlaced without deinterlacing first? That right there will double your crf bitrate while reducing quality.

[Darius510]

You need to manually spot-check your discs' action scenes to see whether they're good or all screwed up. x265 certainly can't do this for you. For MPEG-2 video, there are some good quant-checkers out there, so you can quickly see if the quant is too high throughout the movie (quant has more correlation to quality in MPEG-2 than in newer codecs), then spot-check only the ones with bad numbers.

If a Blu-Ray is so small that a crf 18 is larger than the source, consider keeping the source. If you'd rather leverage the codec, then get rid of the crappy encode artifacts with pre-filtering (an --nr 100 might also help) and/or reduce resolution. Avisynth and ffmpeg have lots of ways you can filter, from lightning fast to slower than molasses. Personally, there's very little point to re-encoding instead of merely archiving if you're not going to make the video look better in the meantime. (If you make it look good enough, then maybe a little extra bitrate isn't unwarranted?) Otherwise, just raise the crf, because garbage in->garbage out, don't waste bits on it.

Are you certain you're not encoding interlaced without deinterlacing first? That right there will double your crf bitrate while reducing quality.


Well, there were some exceptions to the rules. For most movies, CRF 17 gave me a modest reduction. But then I'd have something like "300", which is super grainy, and only 15GB encoded with VC1. That one came out larger. Same deal with full metal jacket, it prob also didn't help that it was a full 1080p. Then on the other hand the two-disc LOTR EE discs are encoded at stupid high bitrates the entire way through and compressed way down to like 20% of their size. I'm sure I could denoise the hell out of them, but then I feel like I'm ruining them.

I still got a whole stack of discs to go through, I've just been getting such variable results in terms of file size that I was thinking maybe I'm not doing something right.

I do have a few interlaced nature docs and they came out WAY bigger...how am I supposed to encode those correctly?

[huhn]

I do have a few interlaced nature docs and they came out WAY bigger...how am I supposed to encode those correctly?

depends on how they are interlaced.

telecine with 3:2 can be fixed with a detelecine filter.

PsF (Progressive Segmented Frame or telecine 2:2) this is kind of not interlaced at all and rare so can be encoded as progressive. I would use a top filed matcher just to be save.

and true interlaced needs a deinterlacer these filter can be terrible slow.

VFR in interlaced very complicated to get this 100% right. a normal deinterlacer is save and shouldn't mess up to hard this content is very rare any way older cartoon or anime are some times like this.

[Darius510]

depends on how they are interlaced.



telecine with 3:2 can be fixed with a detelecine filter.



PsF (Progressive Segmented Frame or telecine 2:2) this is kind of not interlaced at all and rare so can be encoded as progressive. I would use a top filed matcher just to be save.



and true interlaced needs a deinterlacer these filter can be terrible slow.



VFR in interlaced very complicated to get this 100% right. a normal deinterlacer is save and shouldn't mess up to hard this content is very rare any way older cartoon or anime are some times like this.


I'd prefer not to deinterlace it at all if possible. It's a weird encode, the title is "frozen planet"....most of it looks like 24fps film, and interspersed are scenes where it's clearly interlaced video.

[huhn]

I'd prefer not to deinterlace it at all if possible. It's a weird encode, the title is "frozen planet"....most of it looks like 24fps film, and interspersed are scenes where it's clearly interlaced video.

this is a problem of processing not x265. this will go totally of topic. feel free to make a new topic about this people on this forum will help you for sure.

I'd prefer not to deinterlace it at all if possible.

you are doing this at the moment. resulting huge files and theoretical picture problems like 3:2 judder or other things. not sure if you make x265 clear that the input is interlaced but you should do this.

[Darius510]

this is a problem of processing not x265. this will go totally of topic. feel free to make a new topic about this people on this forum will help you for sure.

you are doing this at the moment. resulting huge files and theoretical picture problems like 3:2 judder or other things. not sure if you make x265 clear that the input is interlaced but you should do this.

Is there something about h265 or x265 that can't handle interlacing in the same way as h264?

[huhn]

Is there something about h265 or x265 that can't handle interlacing in the same way as h264?

interlaced material like telecine produce picture like this:
http://abload.de/img/aikatsu63.ts_snapshot95kce.png
http://abload.de/img/aikatsu63.ts_snapshotigjfh.png

these frames are very hard to encode.

x265 works different. I think it take the field and not the frame.

so I guess x265 will be better as x264 or is already.

you can read about this here:
http://x265.readthedocs.org/en/latest/cli.html

in the end the interlaced video has to be deinterlaced at playback. but deinterlacing be for encoding results in better picture quality because you choice the deinterlacer or telecine filter that suites the source best and because progressive frames are easier to encode for both x264 and x265.

detelecine for telecine source does wonders. no 3:2 judder, a lot smaller by better quality and you get the original frames back just awesome.

[Darius510]

interlaced material like telecine produce picture like this:
http://abload.de/img/aikatsu63.ts_snapshot95kce.png
http://abload.de/img/aikatsu63.ts_snapshotigjfh.png

these frames are very hard to encode.

x265 works different. I think it take the field and not the frame.

so I guess x265 will be better as x264 or is already.

you can read about this here:
http://x265.readthedocs.org/en/latest/cli.html

in the end the interlaced video has to be deinterlaced at playback. but deinterlacing be for encoding results in better picture quality because you choice the deinterlacer or telecine filter that suites the source best and because progressive frames are easier to encode for both x264 and x265.

detelecine for telecine source does wonders. no 3:2 judder, a lot smaller by better quality and you get the original frames back just awesome.

I guess I'm not explaining it right...it's not 24-30 progressive fps that are embedded in an interlaced stream. It's more like 1080i video on news, sports, soap operas, etc...where each field is different and it appears as smooth as 60fps. If I deinterlace before encoding, it loses that silky smoothness. The file properties reads 29.97fps, but on playback mpc-hc reads 60fps.

I figured I'd just be able to drop it into handbrake and it would encode into h265 as-is into an interlaced stream, but it doesnt seem to be the case.

[vivan]

interlaced material like telecine produce picture like this:
http://abload.de/img/aikatsu63.ts_snapshot95kce.png
http://abload.de/img/aikatsu63.ts_snapshotigjfh.png

these frames are very hard to encode.

x265 works different. I think it take the field and not the frame.Isn't this basically PAFF which is inferior to MBAFF?

If I deinterlace before encoding, it loses that silky smoothness. The file properties reads 29.97fps, but on playback mpc-hc reads 60fps.That's because you need to deinterlace to 60 fps :)

[huhn]

Isn't this basically PAFF which is inferior to MBAFF?

I don't encode interlaced at all. so no clue. I don't even know what you talking about.


http://x265.readthedocs.org/en/latest/cli.html
HEVC encodes interlaced content as fields. Fields must be provided to the encoder in the correct temporal order. The source dimensions must be field dimensions and the FPS must be in units of fields per second. The decoder must re-combine the fields in their correct orientation for display.

but you are in the best thread to ask about this.

[foxyshadis]

MBAFF is gone in HEVC. (We sigh, but the implementers say good riddance; I can't imagine how horrifying it'd be to implement everything from 4x4 to 64x64 MBAFF.)

Forgotten planet is VFR, which is easy to process these days. However, if you're not willing to do VFR processing, I'd just keep the video as-is, archived without re-encoding, unless it takes up a stupid amount of space. Just mux the raw video and whatever audio you want to keep into mp4 or mkv. All good players (and hardware video processors) can do VFR deinterlacing in real time, and it'll look better than straight-interlaced x265 encoding, especially if it's flagged as pulldown now.

As far as I know there are no freely available HEVC pulldown tools yet.


Again regarding file sizes: If the size is not acceptable, raise the crf or filter more. The encoder won't do this for you. You can't always beat a bad encode, and in that case you should just archive, but you can always fix a bad encode enough that it's worth spending the extra bits.

300 is a particularly insanely challenging movie, with all that digital grain. It was encoded by fine-tuning the encoder and the encoding settings for the movie -- it was an early title that was supposed to show off the superiority of VC-1 over H.264, back when Blu-ray was losing in the market -- but it's only just under 15GB of video. Until a remaster is released (the sequel uses 40% higher bitrate with a mature H.264 codec) you just have to accept that attempting to re-encode it is going to be extremely rough for any encoder.

Of course, if you had a 25GB remaster, and your encoding ended up the same 17GB, would you be happy then, despite being the same content? Source size doesn't matter, it's an artifact. If you think it matters, you need to make the hard decisions about when to reduce quality yourself.

[LigH]

Already several months ago, it was stated that HEVC would not even mention interlacing in the specification, because interlacing is not suitable for web video.

x265 specifically supporting interlacing again is a kind of concession to the "nagging audience"... ;) ;)

[LigH]

x265 1.3+58-c5624effb73c (https://www.mediafire.com/download/5wv13f3bq7pgwdr/x265_1.3+58-c5624effb73c.7z) backed out a possibly incomplete bugfix regarding B-frame bitrate prediction in VBV, causing problems in CBR mode, but re-enabled and fixed --cu-lossless.

[Darius510]

MBAFF is gone in HEVC. (We sigh, but the implementers say good riddance; I can't imagine how horrifying it'd be to implement everything from 4x4 to 64x64 MBAFF.)

Forgotten planet is VFR, which is easy to process these days. However, if you're not willing to do VFR processing, I'd just keep the video as-is, archived without re-encoding, unless it takes up a stupid amount of space. Just mux the raw video and whatever audio you want to keep into mp4 or mkv. All good players (and hardware video processors) can do VFR deinterlacing in real time, and it'll look better than straight-interlaced x265 encoding, especially if it's flagged as pulldown now.

As far as I know there are no freely available HEVC pulldown tools yet.


Again regarding file sizes: If the size is not acceptable, raise the crf or filter more. The encoder won't do this for you. You can't always beat a bad encode, and in that case you should just archive, but you can always fix a bad encode enough that it's worth spending the extra bits.

300 is a particularly insanely challenging movie, with all that digital grain. It was encoded by fine-tuning the encoder and the encoding settings for the movie -- it was an early title that was supposed to show off the superiority of VC-1 over H.264, back when Blu-ray was losing in the market -- but it's only just under 15GB of video. Until a remaster is released (the sequel uses 40% higher bitrate with a mature H.264 codec) you just have to accept that attempting to re-encode it is going to be extremely rough for any encoder.

Of course, if you had a 25GB remaster, and your encoding ended up the same 17GB, would you be happy then, despite being the same content? Source size doesn't matter, it's an artifact. If you think it matters, you need to make the hard decisions about when to reduce quality yourself.


Yeah, I would be happy. I'd feel like h265 was doing it's job in that case. Maybe this sounds weird, but I'm less concerned with file size than I am with the quality/size ratio. I feel like I'm needlessly wasting space using a less sophisticated codec when h265 seems to be superior in every way that matters. I guess I'm not giving enough leeway for the quality of the encodes, I'm just going by codec and size and assuming quality should be directly proportional to that. Perhaps that's oversimplifying it too much.

I've been tinkering a bit and I've been finding that a very light denoise before encoding produces a significantly smaller file size without any noticeable difference in image quality at the same CRF. Seems like the bits can either go towards encoding very faint noise or the underlying picture, and the filter seems to focus the encoder on what matters and ignoring that slight fuzziness that your eye just blends in anyway.

I swear though, this codec is like magic. It's unbelievable how good it looks at ridiculously low bitrates. I tried encoding a few segments of LOTR at 1000kbps, and it looked way better than it had any right to. Although there was a HUGE difference between the presets at low bitrates - veryslow was night and day better than fast, but I can barely tell the difference between them at 10000kbps+.

[Atak_Snajpera]

Regarding FILM tune preset. According to my quick test I have a feeling that default values for --psy-rd , --psy-rdoq , --aq-strength are too conservative for typical film footage. Default values in x264 give much stronger effect than those in x265.

SOURCE -> https://mega.co.nz/#!4BMXAQKC!1K_DE4rpcjGBLOxVtV6C-_L6OUIakxSelxRiOuW8j68

--pass 2 --bitrate 1024 --min-keyint 24 --keyint 240 --rd 4 --psy-rd 1.0 --psy-rdoq 1.0
http://i.cubeupload.com/b6Weps.png
http://www.mediafire.com/download/2p2lmwg1ivmpy3s/video_x265_1.mkv

--pass 2 --bitrate 1024 --min-keyint 24 --keyint 240 --rd 4 --psy-rd 2.0 --psy-rdoq 10.0
http://i.cubeupload.com/ZHaLEI.png
http://www.mediafire.com/download/n7qbgop1qgnptnb/video_x265_2.mkv

--pass 2 --bitrate 1024 --min-keyint 24 --keyint 240 --rd 4 --psy-rd 2.0 --psy-rdoq 10.0 --aq-strength 2.0
http://i.cubeupload.com/RzZIF8.png
http://www.mediafire.com/download/4vnx1uq40mbx3j3/video_x265_2_10_2.mkv

[Blue_MiSfit]

I think the middle of those 3 is actually the most visually consistent. The differences are pretty subtle, and all 3 look pretty good for 1 Mbps 1080p :)! The most aggressive version seems to pull too many bits from the moving areas - look at Morgan Freeman's face when he's talking on this clip relative to the others.

My thoughts are that this clip would be ideal with settings somewhere between the first two examples. Maybe psy-rd 1.5 and psy-rdoq 5

[xooyoozoo]

My thoughts are that this clip would be ideal with settings somewhere between the first two examples. Maybe psy-rd 1.5 and psy-rdoq 5

In the higher settings, I first noticed the extra "halo" of noise around high contrast edges before I noticed any benefits, so I definitely agree.

[Atak_Snajpera]

I agree that last example may be to extreme. I will check 1.5 , 5.0 , 1.5 variant next time.

[Atak_Snajpera]

ACHTUNG! Possible bug detected ;)
x264 https://mega.co.nz/#!xEkD2S4A!2kYRRCiZpoyJp7GaflW5mHTEtb3esPvptK6AUY88lrY
http://i.cubeupload.com/FelGgX.png

x265 https://mega.co.nz/#!1V8jyBTI!T-2vr17fYM7FY29OYBhBciWF7BWzUTJgLpX-Gdc17C8
http://i.cubeupload.com/ib5FWB.png

CMD line :
"C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\tools\avs2yuv\avs2yuv.exe" "C:\Temp\RipBot264temp\job1\job1.avs" -o - | "C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\tools\x265\x265_x64.exe" --pass 2 --bitrate 1024 --stats "C:\Temp\RipBot264temp\job1\job1.stats" --fps 24000/1001 --min-keyint 24 --keyint 240 --frames 173 --sar 8:9 --y4m --output "C:\Temp\RipBot264temp\video.265" -

Latest 8 bit build from http://builds.x265.eu/ was used.

Source -> https://mega.co.nz/#!AAUVQRAS!YRnY4zonYPFqhPke4bv9OHhiNkND_pbZYSGESFHDXns

Script
#VideoSource
LoadPlugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\dgindex\DGDecode.dll")
video=MPEG2Source("C:\Temp\RipBot264temp\job1\job1.d2v")

#Deinterlace
Loadplugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\TIVTC\TIVTC.dll")
video=tfm(video,order=1)

#Decimate
Loadplugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\TIVTC\TIVTC.dll")
video=TDecimate(video)

return video

[LigH]

OK, you mean the artefacts in the lower part; I almost expected you having forgotten a SwapUV() ;)

[Atak_Snajpera]

Another one
http://i.cubeupload.com/3JP9VK.png

SOURCE -> http://www.mediafire.com/download/5bymvdfm8qyof4f/harry.mkv

[a5180007]

Same bug with MSVC build 1.3+59. It comes from the latest commit 62c4779 as 1.3+58-c5624ef is bug-free.

[chenm001]

Thanks your report.
I can reproduce it, debugging...

[x265_Project]

Thanks your report.
I can reproduce it, debugging...
Thanks Min. (chenm001 is one of our lead developers)

[Gravitator]

Maybe this bug is caused by reason non-compliance of resolution / block to the multiplicity of 64x64.

[a5180007]

@x265_Project bug solved, thanks.

EDIT : I have another problem with x265 MSVC 1.3+69:
"x265 --preset placebo park_joy_1080p50.y4m -o pj_placebo.hevc" crashes

All other presets OK. No log recorded, but when debugging with MSVC it crashes upon source/common/quant.cpp line 790 :

789 int ctx = ctxCbf[ttype][cu->getTransformIdx(absPartIdx)];
790 bestCost = totalUncodedCost + SIGCOST(estBitsSbac.blockCbpBits[ctx][0]);


cu->m_trIdx = 3 (should be 0-2), ttype = TEXT_CHROMA_V (2) => ctx = ctxCbf[2][3] undefined

EDIT 2 : seems to be solved with 1.3+114

[HotShot]

jfyi, Intel C++ 2015 is out, so the icl32/icl64 build-scripts need an update. After editing them manually, compiling the source went fine.

[Shevach]

Hi x265 community

i am working with x265 version 1.3+26-5acfb12ec5d1 . According to x265 documentation (http://x265.readthedocs.org/en/default/cli.html#quality-rate-control-and-rate-distortion-options)
the default value of aq-mode is 2 :

Adaptive Quantization operating mode. Raise or lower per-block quantization based on complexity analysis of the source image. The more complex the block, the more quantization is used. This offsets the tendency of the encoder to spend too many bits on complex areas and not enough in flat areas.

disabled
AQ enabled
AQ enabled with auto-variance (default)



However, actually the default of aq-mode is 0 (AQ disabled). Indeed, in param.cpp the following statement is executed:
param->rc.aqMode = X265_AQ_NONE;

So, pls. correct the documentation.