Support for passing ffmpeg options for most commands

[stderr-to-devnull]

Example use cases:

• setting x265 profile - when using crf-search, sample-encode, encode
• setting proper options to handle the encoding of multiple audio tracks - when using encode:
  -c:a:0 libopus -b:a:0 256k -channel_layout:a:0 5.1 -c:a:1 libopus -b:a:1 128k
• setting streams metadata - when using encode:
  -metadata:s:a:0 title="Opus 5.1 @ 256Kbps" -metadata:s:a:1 title="Opus 2.0 @ 128Kbps"

[alexheretic]

This is supported with --enc & --enc-input args (these may be added multiple times).

E.g.

ab-av1 encode -i in.mp4 --crf 32 --acodec libopus --enc b:a=96k --enc metadata:s:a:0=title="Opus 96Kbps" -o out.mkv

Note: use RUST_LOG=ab_av1=debug to see resultant ffmpeg call args.

[stderr-to-devnull]

First, the help states:

--enc <ENC_ARGS>              Additional ffmpeg encoder arg(s). E.g. '--enc x265-params=lossless=1' These are added as ffmpeg output file options

Secondly, --acodec exists.

This led me to believe that --enc is exclusively used for the video encoder and any audio related options could only be set via --acodec, which currently can only be used to set the audio codec used. Also, setting metadata is not related to any encoders so setting it with --enc also did not make sense to me.

I think the help description needs to be refactored, to me it was confusing.

Otherwise, setting the options worked.

By the way, I only used --enc, when should --enc-input be used?

I would have:

--ffm <ARGS>        Additional ffmpeg options. Can be used for passing anything from a/v encoder params to metadata.

[alexheretic]

The two main kinds of work the tool does is "encoding" and "vmaf" with various options. Encoding is done with ffmpeg, --enc args apply additional ffmpeg args for encoding, but not during ffmpeg vmaf calls. So I think the idea of having a --ffmpeg arg is in a way less clear.

More common options have first class args, like --acodec but I don't think it is practical to try to cover all ffmpeg options 1-to-1.

Perhaps we can improve the naming. I can see this being a bit confusing with the vcodec arg being named "encoder".

[stderr-to-devnull]

The reason why I suggested --ffm is precisely because for example using --enc metadata:s:a:0=title="Opus 96Kbps" has nothing to do with any encoder. Furthermore, anything we pass with --enc arg is 100% related to ffmpeg options anyway.

More common options have first class args, like --acodec but I don't think it is practical to try to cover all ffmpeg options 1-to-1.

Never suggested that, actually I proposed indirectly that --acodec could be removed because it is very limited in its current implementation, we can't even choose the bitrate with it.

I would like to know what is the difference between --enc and --enc-input, I only used --enc for everything (audio settings, metadata) and it worked fine. The help description did not help me understand the difference.

Moving forward, I propose two paths to consider:

• refactor help file, remove --acodec (since ab-av1 is only concerned with finding best CRF for video encoding) and I would rename --enc to --ffm (as we established, --enc can be used for any ffmpeg option, not just the ones concerning encoder params)
• if we do want to to have first class arguments:
  • --acodec should be expanded to include the absolute basics like bitrate and channel mapping and most importantly how to handle multiple audio tracks (like in my example: one 5.1 track and one 2.0 track)
  • make a first class argument for encoder profile
  • make a first class argument for metadata items (because currently everything is copied and we end up with incorrect descriptions in titles unless we change via --enc arg like I already did)

TL;DR in my opinion, first class args have either confusing definitions or are too limited in their scope for any practical general use, considering the sources we might want to run through ab-av1

Regarding the --acodec expansion proposition, this is why I suggested in other issues that ab-av1 should expose a config file with some useful defaults, to ensure a consistent and desired behavior.

Example: what to do when multichannel audio stream is present, what encoder to use, what bitrate, force correct channel mapping (seems to be required with Opus), metadata etc. And the same group of settings for 2.0 audio streams. These situations are very common.

The config file options should be internalized and whatever settings are changed in the file are to be considered overrides and announced as such when ab-av1 is run (hey user, this setting was overridden in the config file, just so you know)