[HEVC] x265.EXE: mingw builds

[Selur]

What do I disable or enable to the strip from trees gone?

Ever tried using a higher bit rate?
2Mbit/s for 1920x1080@50 seems to be too low.

[Gravitator]

Then why from frame to frame it teleports the strip? Or are You trying to bribe all banal increasing bitrate and a close eye on a manifest error of forming video. We are testing and not to powder brains to each other (circus).

[Selur]

Then why from frame to frame it teleports the strip?

In your sample: because you used psy-rd and it's broken.
The developers know about it and unless you start committing patches your best option is to wait till the developers fix the problem.

[Gravitator]

Why x265 starts with I > I frame (I-I-B-B-B-P)?

[LigH.de]

Will certainly depend on your material. I could imagine that if your video starts with one completely black frame, the second frame is the first with meaningful content, so it may cost less to start it as Intra instead of predicting it from nothing.

[Gravitator]

Will certainly depend on your material. I could imagine that if your video starts with one completely black frame, the second frame is the first with meaningful content, so it may cost less to start it as Intra instead of predicting it from nothing.

Well, in that order starts DivX and x265 on all samples (it shows me xmedia).

[Selur]

Why x265 starts with I > I frame (I-I-B-B-B-P)?

rate control (and thus frame decision) isn't that good/adaptive atm.

[Gravitator]

Why x265 starts with I > I frame (I-I-B-B-B-P)?

rate control (and thus frame decision) isn't that good/adaptive atm.

This is due to parallelization of the encoding / decoding? Even Elecard (all HEVC) obey this manner.

[Selur]

a. Has nothing to do with decoding.
b. parallelization does influence rate control, but I doubt this is the cause
-> HEVC encoders simply are not that mature as lots of people like to believe (frame decision, rate control and a lot of other basic things are are only roughly implementet atm.

[LigH.de]

Is this the coded order or the display order?

[Selur]

should be display order.

[LigH.de]

v1.1+202-e2ed009d296a introduces Psy-RDO for RD levels 2..4; but without an official "all-clear", don't expect it to be completely "fixed" yet.

[Selur]

does '--psy-rd' work with the latest version or does is still produce artifacts?

[LigH.de]

I just even built it; when do you expect me to have tested it? Do test it yourself and tell us!

[Selur]

didn't know you just build it.

[LigH.de]

Usually I check the repo in the morning and afternoon, and try to upload a build each time I recognize some important addition or fix, or the stable branch got merged with the default. So any of you can rather quickly download and test. My hardware is not best suited for encoding tests, you know (AMD Phenom-II).

[Selur]

x265 --input - --input-res 440x80 --fps 24 --frames 240 --ctu 16 --crf X   --psy-rd 0.5 --no-cu-lossless --output "H:\Temp\x265_13_34_07_6710_01.265"

with seems to be okay on avisynths 'version()' as long as the crf is relatively low. (x264 with a 6 point higher crf looks worse)

[LigH.de]

The Version script is a clean still. You may not easily spot any Psy-RDO issues with no motion at all. I'd rather recommend "foreman" or the varun samples (Johnny, KristenAndSara, FourPeople).

[Selur]

I know, but the last time even the version() encode was full of artifacts, so that got better.

[LigH.de]

I didn't know that the Version script provoked artefacts too...

The varun samples certainly do. I'll upload new results soon: FourPeople_1280x720_60.yuv encoded with

--preset fast --psy-rd {0.0—1.0} --aq-mode 2 --aq-strength 2.0

but as far as I can already see, Psy-RDO does not yet certainly enhance visuals.

And on top of that, I wonder which era the "mode" of the woman is based on; could have been my mom in the GDR in early 80's...

[LigH.de]

x265 v1.1+223-976dc15ea5ea was a stable-merge again.

Additionally, v1.1+250-1dc27824bde1 contains new features: I/P/B quantizer ratios, and lambda files to exchange tables. Both topics should be considered "advanced, don't change if you don't know it better than the developers for sure".

[DarrellS]

All but one of my custom presets are broken since 1.1.

--preset ultrafast --crf 14 --input-res %(width)x%(height) --fps %(fps) - -o "%(tempvideofile)"

...is the only one that works. I'm back to corrupt files. First frame black, 2nd frame good, last frame good. All in between frames are gray.

Normal preset works...

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

[Selur]

I just tried:

mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "F:\TESTCL~1\test.avi" | x265 --input - --input-res 640x352 --fps 25 --frames 429 --crf 14   --output "H:\Temp\test_16_54_37_3210_01.265"

and the output is fine.

I'm surprised that:

--preset ultrafast --crf 14 --input-res %(width)x%(height) --fps %(fps) - -o "%(tempvideofile)"

works for you, since to me it looks like you are missing a '--input',...

-> Did you build the binary yourself? Where did you get the binary from?

[LigH.de]

@ Selur:

The parameter "--input" is rather optional if the set of parameters is unambiguous.

Syntax: x265 [options] infile [-o] outfile

__

@ DarrellS:

Without more details about "all the other presets", the sources, the output, and the used decoder, your problem cannot be solved. I would suspect your decoder to fail with some new encoder feature which is only present in any slower but the "ultrafast" preset; but I don't know "all your other presets"...

[DarrellS]

OK, it seemed to not like my input file resolution at 3840x2400. Cropped to 3840x2160 and all presets worked. Looking back a couple of pages though it looks like speed has dropped in newer builds when it was supposed to have increased. I even overclocked my CPU from 2.44 to 3.00 and speeds are still slower. My fastest encode was 3.2 fps with this command argument...

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

This preset gives me 13.3 Mbps at 3.2 fps
x264superfast gives 11.1 Mbps at 9.6 fps

@Selur, input is right before output... - -o

[LigH.de]

Don't tell me you still encode with a 32-bit encoder? Would be no real surprise if frame dimensions larger than 2160p exceed 2 GB process memory for a more complex preset than the fastest few.

Overclocking destabilizes the PC. Don't do that.

German proverb by car tuners: "There is no substitute for cylinder capacity. Except more cylinder capacity."

[DarrellS]

No, I moved to Windows 7 64 bit a couple of months ago but it uses twice as much memory as XP did and I can't afford to buy more memory (or a modern day I5 or I7 PC) right now. Too many doctor bills and not a big enough Disability check.

[Gravitator]

last build better and better encode "park_joy_1080p50.y4m" become acceptable

[LigH.de]

Version 1.2 is coming soon™; in the meantime, have v1.1+258-6623f1195baa (most recent stable+default merge) in my MediaFire archive.

[LigH.de]

Despite a few compiler warnings, I uploaded x265 v1.2+82-6055baa75085 as another merge-with-stable release.