x265 HEVC Encoder

[davidsama]

That dropbox link gives me a Error (403) message when i click on it.

[LoRd_MuldeR]

So what is the recommended --psy-rdoq value for general purpose encoding, is it still 1.0 ?

The docs still say that "1.0 is a typical value. Default disabled."

Anyway, the commit message says:
api: allow --psy-rdoq values up to 50; it can be beneficial for film grain

See also:
http://x265.readthedocs.org/en/default/cli.html#cmdoption--psy-rdoq

[Romario]

x265 project, please give us OFFICIAL Change Log for 1.4. Thanks.

[lotusgg]

7 posts before. (https://www.doom9.org/showpost.php?p=1698383&postcount=1398)

[fauxreaper]

I'm trying to use x265 to encode still images, using an AVS script + avs4x265, but there's a problem when encoding one image.

The image is http://www.gulfstockphoto.com/downloads/cabs/ , with 3264x2448 pixels.

The AVS script is:

ImageSource("E:\25H.jpg",start=0,end=0,fps=24)
ConvertToYV12()

The command line is:

avs4x265 --preset placebo --crf 25.0 taxi.avs -o taxi.hevc

The x265 version is 1.3+788, 64bit 8bpp.

The output has pink blocks. I tried to decode it using LAV Video Decoder 0.63.0 and the recent version of Strongene Decoder, but the output is the same.

Screenshot taken on MPC: http://imgur.com/dgz08RO

[LoRd_MuldeR]

x265 v1.4, 32-Bit/64-Bit, 8bpp/16bpp:
http://sourceforge.net/projects/muldersoft/files/x265%20HEVC%20Encoder/x265-Windows-VC2013.2014-11-02.zip/download

[LigH]

Me too; nothing special, as usual a simple GCC 4.8.2 build: x265 1.4+5-eebb372eec89 (https://www.mediafire.com/download/g3hkp0po4koa1fm/x265_1.4+5-eebb372eec89.7z)

[YamashitaRen]

Hello,
I'm trying x265 but I have a weird chroma bug ...
There is an x offset in the red? colors.
Look at Rin's pullover : http://screenshotcomparison.com/comparison/98530

x265 version is current git.
x265 input is 16 bit piped y4m.
x265 output is 10 bit.
Preset is slow.
I did the screens with mpv --vo=image.

Any idea ? :)

[mandarinka]

This is probably not x265's fault.

To me it seems that during the decoding step, MPV uses center-mid (MPEG1) chroma placement during conversion to RGB, while for x264-encoded file, the correct MPEG2 chroma positioning is used (which is left-mid). The result is that chroma information is effectively shifted to right for x265's encode.

It could be x265's fault if it incorrectly flags the bitstream, thus making MPV to pick mpeg1 chroma positioning (btw, this might also behave differently based on what you use for rgb conversion - swscale, gpu drivers, MPV's opengl VO etc. --vo image probably uses swscale though).

Anyway, this thing should be introduced when converting 4:2:0 yuv to rgb, so it really shouldn't be x265's doing. It's more likely to be MPV (or swscale) bug. Or you somehow introduced the shift before encoding, but I find that unlikely.

[LigH]

I found that x265 does insert aspect ratio flags in its encoded video streams, but neither MediaInfo (which MPC-HC relies on) nor VLC appear to detect them and therefore don't deskew HEVC video. I created bug tasks in their respective trackers.

[Kurtnoise]

You should post a sample...that helps a lot the developers.

[LigH]

That will follow soon™...

[nevcairiel]

I found that x265 does insert aspect ratio flags in its encoded video streams, but neither MediaInfo (which MPC-HC relies on) nor VLC appear to detect them and therefore don't deskew HEVC video. I created bug tasks in their respective trackers.

MPC-HC doesn't use MediaInfo during playback for Aspect Ratio.

[LigH]

In this case, LAV Filters may be responsible (if used for decoding)? So I'll consider you notified.

Samples: foreman_cif_sar-test.7z (http://www.ligh.de/tmp/foreman_cif_sar-test.7z)

[nevcairiel]

In this case, LAV Filters may be responsible (if used for decoding)? So I'll consider you notified.

Samples: foreman_cif_sar-test.7z (http://www.ligh.de/tmp/foreman_cif_sar-test.7z)

Seems to be working fine during playback.
I get videos scaled to 385:288 (128-117), 384:288 (sar2) and 352:288 (no-ar)

[LigH]

OK, here you are right: Playback of raw *.hevc in MPC-HC 1.7.7 respects the AR; playback of *.mp4 (multiplexed with MP4Box - GPAC version 0.5.1-DEV-rev5261) does not. Maybe I should try again with a nightly MP4Box...

foreman_cif_sar-mp4s.7z (http://www.ligh.de/tmp/foreman_cif_sar-mp4s.7z) — multiplexed with MP4Box - GPAC version 0.5.1-DEV-rev5491: Always SAR 1.0. If MPC-HC prefers container AR flags, then MP4Box will probably not have recognized HEVC AR flags to repeat them in the MP4 container (if the MP4 container supports video stream AR flags at all).

Nevertheless, MediaInfo always reports AR 1.0, for raw *.hevc too. I wonder if L-SMASH supports HEVC AR flags.

[Kurtnoise]

But did you put the sar directly in the command line for the mux or not ?

[LigH]

I did not tell MP4Box manually about an AR, I expected it to detect it from the video stream... :o

[Selur]

*gig* it doesn't, never did :)

[nevcairiel]

OK, here you are right: Playback of raw *.hevc in MPC-HC 1.7.7 respects the AR; playback of *.mp4 (multiplexed with MP4Box - GPAC version 0.5.1-DEV-rev5261) does not. Maybe I should try again with a nightly MP4Box...

foreman_cif_sar-mp4s.7z (http://www.ligh.de/tmp/foreman_cif_sar-mp4s.7z) — multiplexed with MP4Box - GPAC version 0.5.1-DEV-rev5491: Always SAR 1.0. If MPC-HC prefers container AR flags, then MP4Box will probably not have recognized HEVC AR flags to repeat them in the MP4 container (if the MP4 container supports video stream AR flags at all).

Nevertheless, MediaInfo always reports AR 1.0, for raw *.hevc too. I wonder if L-SMASH supports HEVC AR flags.

By default, MPC-HC/LAV will prefer the container AR of MP4 files. You can change that mode by toggling the "Use Stream AR" option in LAV settings.

[Kurtnoise]

Nevertheless, MediaInfo always reports AR 1.0, for raw *.hevc too.
looking at the code, this part is not available yet for hevc streams...That's why it's still 1.0 as default. Maybe I should create a patch for that.

[LigH]

Looking forward to it. :)

At least it was not the fault of x265.

[YamashitaRen]

This is probably not x265's fault.

To me it seems that during the decoding step, MPV uses center-mid (MPEG1) chroma placement during conversion to RGB, while for x264-encoded file, the correct MPEG2 chroma positioning is used (which is left-mid). The result is that chroma information is effectively shifted to right for x265's encode.

You're right. I had trouble playing the hevc stream in vlc but concatenating it in a mkv solved the problem.
The chroma placement is indeed good in vlc so it should be a mpv problem (edit, ffmpeg seems to be the culprit) as you said. Using vo=opengl=chroma-location=left in mpv solved the problem too.
Now i have to fill a bugreport upstream and find how to do my screenshoots until the bug is fixed.

Thank you for the detailed explanation :)

edit : found it !
We can use vapoursynth inside mpv, so I'm using fmtconv to shift the chroma placement from MPEG2 to MPEG1.

[Kurtnoise]

Looking forward to it. :)
Basically, something like that (http://pastebin.com/vfDm2uyk)...

Before applying the patch :
General
Complete name : C:\Users\duchatl\Documents\foreman_cif_sar-test\foreman_cif_128-117.hevc
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 259 KiB
Writing library : x265 1.4+5-eebb372eec89:[Windows][GCC 4.8.2][64 bit]
Encoding settings : wpp / ctu=64 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=20 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / weightp / no-weightb / aq-mode=2 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=0.00 / psy-rdoq=0.00 / signhide / lft / sao / no-sao-non-deblock / b-pyramid / cutree / rc=crf / crf=28.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L2.0
Width : 352 pixels
Height : 288 pixels
Display aspect ratio : 1.222
Frame rate : 29.970 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 1.4+5-eebb372eec89:[Windows][GCC 4.8.2][64 bit]
Encoding settings : wpp / ctu=64 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=20 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / weightp / no-weightb / aq-mode=2 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=0.00 / psy-rdoq=0.00 / signhide / lft / sao / no-sao-non-deblock / b-pyramid / cutree / rc=crf / crf=28.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30


After applying the patch :
General
Complete name : C:\Users\duchatl\Documents\foreman_cif_sar-test\foreman_cif_128-117.hevc
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 259 KiB
Writing library : x265 1.4+5-eebb372eec89:[Windows][GCC 4.8.2][64 bit]
Encoding settings : wpp / ctu=64 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=20 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / weightp / no-weightb / aq-mode=2 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=0.00 / psy-rdoq=0.00 / signhide / lft / sao / no-sao-non-deblock / b-pyramid / cutree / rc=crf / crf=28.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L2.0
Width : 352 pixels
Height : 288 pixels
Display aspect ratio : 4:3
Frame rate : 29.970 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 1.4+5-eebb372eec89:[Windows][GCC 4.8.2][64 bit]
Encoding settings : wpp / ctu=64 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=20 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / weightp / no-weightb / aq-mode=2 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=0.00 / psy-rdoq=0.00 / signhide / lft / sao / no-sao-non-deblock / b-pyramid / cutree / rc=crf / crf=28.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30

[LigH]

Seems to be the required change. OK to reply to the bug report (https://sourceforge.net/p/mediainfo/bugs/877/) with this link?

[Kurtnoise]

sure...no problem.

[Darius510]

I see that handbrake nightly has been updated to x265 1.4, but for the life of me I can't figure out the syntax to use pmode in the extra options field. Can anyone help?

Also, is there ever a chance of x265 supporting continuing a partial encode? It can take hours to encode a video, and if I ever need to reboot, I have to start all over again.

[LigH]

1. If you want to enable "Parallel mode analysis", you probably just have to add: --pmode (it is disabled by default, which is like using --no-pmode).

2. Already discussed many times: The more complex a video format is (with lots of references between many frames, possibly even weighted ones), the harder it would be to store a whole encoder state to continue from any arbitrary position. Continuing from an IDR frame would be possible, but they are sparse. If you already knew that you don't want to encode a whole video before starting, you could of course limit the range to be encoded, and later join the partial results.

[Atak_Snajpera]

I see that handbrake nightly has been updated to x265 1.4, but for the life of me I can't figure out the syntax to use pmode in the extra options field. Can anyone help?

Also, is there ever a chance of x265 supporting continuing a partial encode? It can take hours to encode a video, and if I ever need to reboot, I have to start all over again.

Just use ripbot in distributed encoding mode. In this way you can resume encoding from last encoded chunk.

[Darius510]

1. If you want to enable "Parallel mode analysis", you probably just have to add: --pmode (it is disabled by default, which is like using --no-pmode).

I see the problem now is that even though they patched 1.4 into the codebase two days ago, they havent updated the nightly build DL with that version yet. I tried it with ripbot though and pmode is a solid 10-20% speed boost on my 5820K. Nice! Adding pme slowed things back down a bit, even though pmode itself wasnt fully saturating 100% of the time.

2. Already discussed many times: The more complex a video format is (with lots of references between many frames, possibly even weighted ones), the harder it would be to store a whole encoder state to continue from any arbitrary position. Continuing from an IDR frame would be possible, but they are sparse. If you already knew that you don't want to encode a whole video before starting, you could of course limit the range to be encoded, and later join the partial results.

I don't always know that ahead of time though. Encoding a 2 hour movie at high settings can take 20+ hours even on a overclocked hex-core haswell-E. Some method to manually pause an encode or pick up after an unfortunate crash would be incredibly useful. It doesn't have to be any arbitrary position, just some way to salvage a few hours of encoding if things don't go as planned.

[LigH]

I am not sure if it would be possible to store a kind of "encoder state file" each time an IDR (would be in H.264; there is certainly something alike in H.265) frame is to be encoded, flushing the output and keeping the bitstream byte position; not my depth of insight.

[Darius510]

I am not sure if it would be possible to store a kind of "encoder state file" each time an IDR (would be in H.264; there is certainly something alike in H.265) frame is to be encoded, flushing the output and keeping the bitstream byte position; not my depth of insight.


Couldn't it just scan a partially encoded file and find an appropriate place to pick up?

I dunno, maybe this is a job for a front end and not the encoder itself. I just dunno of any software that allows you to do this with x265 in a sane way. Considering how epic these encodes can be I think it's really important though.

[LigH]

Scanning for the last position of an IDR frame to continue from would take a lot of time too (means, the encoder would have to implement a partial decoder = HEVC parser too). If this feature would ever be implemented, then probably with a saved "last known good" position... IMHO. I am no developer here. But if, then it would have to be done in the encoder, because it needs to seek the output file to that position to overwrite and append from there. A GUI won't be able to support that.

[Darius510]

Roughly how far apart are these frames anyway?

[LigH]

Depends on the distance of scene cuts and the parameters limiting them ... but with defaults, possibly up to 300 frames (~ 10 seconds playback time for NTSC rates).

[Darius510]

Depends on the distance of scene cuts and the parameters limiting them ... but with defaults, possibly up to 300 frames (~ 10 seconds playback time for NTSC rates).

So worst case it would just have to scan the last few megabytes, how bad can that be?

[benwaggoner]

I just noticed a very large and intriguingly named commit: "refine deblocking filter"
https://bitbucket.org/multicoreware/x265/commits/65e14d5a5728a45c0c4ad6a52d2385f1cf47b6f4
Any hints as to what its impact is?

[Selur]

looks like code refactoring, so may be some speed improvement

[x265_Project]

I just noticed a very large and intriguingly named commit: "refine deblocking filter"
https://bitbucket.org/multicoreware/x265/commits/65e14d5a5728a45c0c4ad6a52d2385f1cf47b6f4
Any hints as to what its impact is?
Minor performance improvements, mostly a cleanup. Output is unchanged.

[lotusgg]

How to use deblock?
--deblock=-2
--deblock -2
--deblock=-2:-2 and
--deblock -2:-2 all gives me errors.

edit:
I was using latest stable version(1.4).
I didn't realized it had no deblocking filter yet.
Using 1.4+5 now, but it's too slow. http://prntscr.com/54298r
It usually hits 12fps.

[foxyshadis]

--deblock -2 and --deblock -2:-1 work as expected for me. Make sure you're using a 1.4 build.

[LigH]

sure...no problem.

MediaInfo accepted it.

[lotusgg]

Found a bug when testing anime.
Seems like the --rd 0 part from this cli (http://prntscr.com/54eqks) is making the CTUs go crazy and operate 64x64 only.
http://www.solidfiles.com/d/e2aab668a2/00000_4.hevc

source is 00000.m2ts from this file (http://www.nyaa.se/?page=download&tid=579873).

[a5180007]

Steve Borho on the x265 developers IRC :


2014-11-06 16:57:25 <@muggs> our default AQ mode is 2 (auto-variance); I'm not real convinced this is a good thing

[upyzl]

x265 has introduced --tune grain (http://x265.readthedocs.org/en/default/presets.html#film-grain-retention)

anyone tested? especially retain details compared to x264 :D

(also compiled latest x265 1.4+48: https://mega.co.nz/#F!Nx8GgL6Y!tlxzo_GpGmEhptwa4vKgLw contained 8bpp&16bpp
aims to fastest for me, so Win64 & CPU support AVX is needed)

[uneedme]

run encode in vmware virtual os

feasible to pause anytime

[uneedme]

Couldn't it just scan a partially encoded file and find an appropriate place to pick up?

I dunno, maybe this is a job for a front end and not the encoder itself. I just dunno of any software that allows you to do this with x265 in a sane way. Considering how epic these encodes can be I think it's really important though.

you might run encode in vmware virtual OS

it is feasible to pause anytime

and you are affordable to a little bit efficiency lose

just like hot hibernation mode

[lotusgg]

Tried to simulate this -tune grain here (https://www.doom9.org/showthread.php?p=1699083#post1699083), but without the qcomp adjustments(can't compile, latest posted here is 1.4+5).

[x265_Project]

x265 has introduced --tune grain (http://x265.readthedocs.org/en/default/presets.html#film-grain-retention)

anyone tested? especially retain details compared to x264 :D

(also compiled latest x265 1.4+48: https://mega.co.nz/#F!Nx8GgL6Y!tlxzo_GpGmEhptwa4vKgLw contained 8bpp&16bpp
aims to fastest for me, so Win64 & CPU support AVX is needed)

We're still working to improve how x265 handles film grain. We'll provide an update and suggested settings for grainy material when we're a little further along.

[LigH]

In the meantime, I uploaded x265 1.4+47-1e04e178a349 (https://www.mediafire.com/download/13xxnm6t36kb8bt/x265_1.4+47-1e04e178a349.7z) (Win32/XP+ and Win64/Vista+).