Feature request: Allow reordering of VPP filters (e.g., run --vpp-subburn after --vpp-pad)

[feureau]

Problem

NVEncC currently executes its hardware‑accelerated VPP filters in a fixed, hard‑coded order:

1. --vpp-subburn
2. --vpp-resize
3. --vpp-pad

This order prevents a common use case: converting horizontal content (e.g., 16:9) to vertical (9:16) by adding top/bottom black bars with --vpp-pad, while burning subtitles that appear inside those padded bars (or centered on the final canvas).

Because --vpp-subburn runs before padding, subtitles are rendered on the original frame – they become clipped, squashed, or never land in the black area.

Desired behaviour

A general mechanism to reorder the VPP filter chain so that users can specify, for example:

• --vpp-order "pad,subburn" (pad first, then burn subtitles on the full padded frame)
• Or --vpp-filter-chain "subburn,resize,pad" for complete control

This would also enable other custom orders (e.g., resize before subburn, overlay before pad, etc.).

Why existing workarounds are not sufficient

Workaround	Limitation
Pre‑processing with ffmpeg/libav	Adds extra pass, re‑encoding, or pipe complexity.
VapourSynth/AVISynth input	Requires external scripting environment and additional setup.
--vpp-overlay	Runs after padding but does not accept text subtitles (only images/video).
--vpp-libavfilter	Often incompatible with hardware path (--avhw); may not support all subtitle filters.

Precedent in other Rigaya tools

QSVEnc (another Rigaya encoder) has experimental support for reordering VPP filters. A similar mechanism in NVEncC would bring feature parity and resolve a frequently requested limitation.

Additional context

• NVEncC version: 9.13 (verified)
• Platform: Windows (but issue is platform‑agnostic)
• Confirmed fixed order via --help output (no --vpp-order or --vpp-filter-chain flag exists)
• Related past issue: --vpp-pad and --vpp-overlay encoding priority #467 (user reported logo overlay always applied before padding – developer confirmed "Fixed order")

Request

Please consider adding a general VPP filter reordering mechanism (e.g., --vpp-order or --vpp-filter-chain). I am willing to test a development build if this is feasible.

Thank you for maintaining NVEncC.

[rigaya]

I've been cosidering on --vpp-order for quite some time, and it is partially technically feasible within the current internal implementation. I do recognize that it could be useful in certain scenarios.

However, I've been hesitant to adopt it due to serious concerns about potential side effects.

• Compared to the current fixed approach, introducing this flexibility would result in a vast number of possible combinations. This would significantly increase the complexity of debugging, and I'm not confident that it can be handled reliably.
• In particular, when resolution is involved, the interaction with options such as --output-res becomes quite complicated. This could easily lead to subtle bugs and unintended behavior.

For these reasons, I've been cautious about moving forward with this feature...