FFmpeg doesn't pass -x265-params to the x265 encoder correctly.

[Vladimir Kazakov]

Hi!

Summary of the bug:
When I'm trying to pass x265 parameters by using -x265-params, multiple issues happen:

1. Some parameters may be reported as "unknown". For example, the --profile option (​http://x265.readthedocs.org/en/default/cli.html#cmdoption--profile) is being reported as unknown (see: unknown-report.log, line 98).
2. If a switch parameter was specified (the parameter that doesn't need a value, for example --no-scenecut (​http://x265.readthedocs.org/en/default/cli.html#cmdoption--scenecut)), then parameters (even the correct ones) are not passed to x265 at all. Without any warnings or errors (see: ignore-report.log and ignore-output.log). At the same time, if the problematic switch parameter is replaced with its "key=value" version (for example: --scenecut 0), then parameters are being successfully passed to the encoder.

So, it seems that the problem is complex, and not related only to specific x265 parameters.

How to reproduce:

1. ffmpeg.exe -r 24 -i "1080-png\sintel_trailer_2k_%04d.png" -c:v libx265 -x265-params "profile=main:level=3.0:crf=28:keyint=48:min-keyint=48:scenecut=0" -r 24 -pix_fmt yuv420p -filter:v "scale='trunc(oh*a/2)*2:360'" "360p-hevc.mp4"
2. ffmpeg.exe -r 24 -i "1080-png\sintel_trailer_2k_%04d.png" -c:v libx265 -x265-params "profile=main:level=3.0:crf=28:keyint=48:min-keyint=48:no-scenecut" -r 24 -pix_fmt yuv420p -filter:v "scale='trunc(oh*a/2)*2:360'" "360p-hevc.mp4"

[Josh04]

It's perhaps useful to note that x265 doesn't have any usable alternative profiles at the moment. It lists main, main10 and mainstillpicture but the choice of the first two depends entirely on whether or not it's compiled with HIGH_BIT_DEPTH and the latter isn't implemented at all.

[Peter Cordes]

ffmpeg can't parse keys without values (for x264-params, x264opts, x265-params, etc), since they all use AVDictionary. (edit: actually x264opts used its own custom key=value:key=value parser. That was something I changed.)

I have a patch I've been working that adds support for it. There was a previous never-committed patch that I found later, to do the same thing: ​http://ffmpeg.org/pipermail/ffmpeg-devel/2013-July/146329.html

I've been sitting on my patch, but I should post it, and my cleanups to libx264.c and libx265.c. I'll get to it probably tomorrow.

[Peter Cordes]

Patches at ​https://github.com/FFmpeg/FFmpeg/pull/118.

Sorry, tomorrow, 5 weeks, whatever. I do have ADHD, but that's longer than my usual side-tracks. :P

[Cody Opel]

A relevant issue I hit, if you pass any key without a value, x265 ignores all key/values and uses the defaults without any errors or warnings.

'key='
e.g. -x265-params key=value:key=:key=value

If you run this example you will see that the values are never set and no error is returned about the invalid keys (values chosen at random because they differ from the defaults):

ffmpeg -i "<any random video>" -an -c:v libx265 -x265-params 'aq-mode=0:invalidkey=:keyint=4:min-keyint=30:anotherinvalidkey=value:rd=5' test.mkv

It doesn't matter what the key is, valid or not it will always trigger this behavior.

I tested this with all combinations of ffmpeg 2.6-master(2016-02-08) & x265 1.7-1.9 originally suspecting an api change from an update broke something I was doing.

[Gyan]

Profiles are not passed via x265-params and require a separate CLI switch, added in Dec '17 as dc7d5f9f1904faebab73f5de60f2c360c8255333

The unpaired key-value issue concerns libavutil and requires that the value be always provided, as mentioned above.