Fix x265 2-pass params

[Y0ba]

Seems like it was copypasted from x264, but in x265 some options are different. Plus added --analysis-reuse-file option which is used for --multi-pass-opt-analysis and --multi-pass-opt-distortion and ignored if neither specified.

[redzic]

Thanks again! Looks like it needs a rebase though.

[Y0ba]

Rebased.

[redzic]

Hmm, it looks there's 2 issues now.

1. The default x265 options (specified by av1an) don't work with 2-pass. Something about CRF mode being incompatible with 2-pass. Perhaps we could change the default x265 options if 2-pass mode is enabled.
2. The frame counting seems to count the first pass as well, which is not supposed to happen. This causes the progress bar to go past 100%. I'll see if I can figure out the cause of this.

[redzic]

The cause of the second issue seems to be that the parsing code relies on returning None based purely on the output, without prior knowledge of the encoding pass. This is not possible with the output of x265 in 2-pass mode, since it doesn't seem to specify the pass in each line. The "real" fix would be to not actually parse the first pass progress. I'll try to open a PR that does this, so that this PR can work with minimal friction.

[redzic]

Rebasing should fix the second issue.

[Y0ba]

Error in the first issue is:
Constant rate-factor is incompatible with 2pass without vbv-maxrate in the previous pass
It's possible to specify --vbv-bufsize 35000 --vbv-maxrate 35000. 35000 Should be safe for all hardware decoders, and more than enough for default --crf 25 which probably will never be capped.

[Y0ba]

Or it's possible to just use --level-idc 5.1 (or 4.1, but it doesn't support 4k). Then vbv will be automatically adjusted according to specified level.

[redzic]

Specifying --level-idc 5.1 seems fine to me. The function get_default_arguments would have to be updated to take in the number of passes, and of course the function body as well too.

[Y0ba]

--level-idc 5.1 can be specified for single pass too. It won't change much except making video incompatible with some old hardware decoders. In my tests by default x265 encodes videos with 4.1 level, but maybe that depends on resolution and fps.

[redzic]

I see, thanks. In that case that makes things even more simple. Not sure if we want to detect which profile to use based on the resolution, but I'm fine with simply adding --level-idc 5.1 to the default x265 parameters.

[Y0ba]

I think 4.1 might be a good default. 4k almost always comes with hdr and it requires specifying custom flags (at least --transfer, --colormatrix and --colorprim). I'm not sure anyone will use default settings for 4k encodes.

[redzic]

That seems OK, but for some reason I seem to get infinite stalling with 4k SDR with --level-idc 4.1 with 2-pass mode (although there is an error message when using 1-pass). I would prefer if the default settings do at least work or at the very least display a proper error message.

[Y0ba]

Yeah, in 2 pass encodes if encoder fails in 1 pass, then it just stalls. That's #240 I think.

[redzic]

That shouldn't be the case anymore as of the Rust version. The issue you linked was opened when the project was still written in Python. If I add an invalid option to the first pass on purpose (like, in the compose_1_2_pass function itself), the error is correctly reported:

ERROR [av1an_core::broker] [chunk 1] encoder failed 3 times, shutting down worker
ERROR [av1an_core::broker] [chunk 1] encoder crashed: exit status: 1
stdout:

stderr:
        Error: Unrecognized option --invalid-option

        Usage: aomenc <options> -o dst_filename src_filename
        Use --help to see the full list of options.


source pipe stderr:

ffmpeg pipe stderr:

The strange thing is that the x265 processes still exist, it just stalls infinitely with 1-2% CPU usage.

[Y0ba]

OK, I've added 5.0 level which is a nice middle-ground since it supports 4k (up to 32fps) and can be hw-decoded even in my old tablet made in 2016.

[redzic]

Seems fine to me. Thanks!