Opened 3 years ago

Last modified 18 months ago

#4284 open defect

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

Reported by: kvssoft Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: libx265
Cc:, Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no



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 ( 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 (, 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"

Attachments (3)

ignore-output.log (3.6 KB) - added by kvssoft 3 years ago.
ignore-report.log (110.0 KB) - added by kvssoft 3 years ago.
unknown-report.log (111.5 KB) - added by kvssoft 3 years ago.

Download all attachments as: .zip

Change History (12)

Changed 3 years ago by kvssoft

Changed 3 years ago by kvssoft

Changed 3 years ago by kvssoft

comment:1 Changed 3 years ago by 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.

comment:2 Changed 3 years ago by pcordes

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:

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.

Last edited 3 years ago by pcordes (previous) (diff)

comment:3 Changed 3 years ago by pcordes

  • Status changed from new to open

Patches at

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

comment:4 Changed 3 years ago by pcordes

  • Cc added

comment:5 Changed 2 years ago by cehoyos

  • Component changed from ffmpeg to undetermined
  • Keywords libx265 added; FFmpeg x265 x265-params HEVC H.265 removed

comment:6 Changed 2 years ago by Redyah

  • Priority changed from normal to important

comment:7 Changed 2 years ago by cehoyos

  • Priority changed from important to normal

comment:8 Changed 21 months ago by codyopel

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.

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.

comment:9 Changed 18 months ago by ignisf

  • Cc added
Note: See TracTickets for help on using tickets.