--recode-audio=copy cannot be distinguished from the default, so an impossible copy is silently re-encoded instead of refused

[crippledgeek]

Found by research after #637 shipped (PR #644). #644's behaviour is correct for the default case and arguably wrong for an explicit request; the blocker is that rdlp cannot tell them apart.

What upstream actually does

Verified from source, not paraphrase:

• FFmpegVideoConvertorPP._options calls stream_copy_opts(False) — -c copy is never emitted. yt-dlp's recode verb has no copy mode at all; it always re-encodes when the extension differs.
• FFmpegVideoRemuxerPP._options is stream_copy_opts() (copy=True) with no compatibility check; when ffmpeg rejects the copy, real_run_ffmpeg raises FFmpegPostProcessorError with ffmpeg's own last stderr line. The README is explicit: "If the target container does not support the video/audio codec, remuxing will fail."
• ffmpeg never auto-falls back from -c copy to encoding.

So the two verbs are deliberately separated: copy-or-fail lives under remux, always-re-encode lives under recode, with no cross-contamination. Neither tool has a "copy, and quietly substitute an encoder if that doesn't work" mode — which is what rdlp does today.

Source: https://github.com/yt-dlp/yt-dlp/blob/master/yt_dlp/postprocessor/ffmpeg.py, https://github.com/yt-dlp/yt-dlp/blob/master/README.md

The problem

RecodeAudioMode::Copy is #[default] (crates/rdlp-types/src/recode_audio_mode.rs) and PostProcess::recode_audio is a non-optional RecodeAudioMode (postprocess.rs:174). By the time RecodeStage sees it, these are the same value:

• the user typed --recode-audio=copy — an explicit demand
• the user typed nothing — rdlp's own optimisation ("copy the audio if you can")

The information exists at the CLI boundary (Args::recode_audio is Option<String>) and is discarded during merge.

Consequence: for a container that provably cannot carry the codec (webm/mpg/ogg + aac), #644 re-encodes to the container's default and warns. Right for the default; wrong for the explicit request, where yt-dlp's contract says fail.

Hard-failing unconditionally is not the fix — it would break the default configuration, since --recode-video=webm with no audio flag would start erroring on any AAC source.

Proposed

Preserve the distinction, then branch on it:

• PostProcess::recode_audio: Option<RecodeAudioMode> — None = "not specified", matching the Option-as-inherit convention the desktop overlay already uses (see Desktop: should settings.json materialise defaults and be authoritative over config.toml? #610's verdict; do NOT materialise the default into settings.json).
• Not specified + copy impossible → re-encode with the current warn! (today's behaviour, matches yt-dlp recode).
• Explicitly copy + copy impossible → refuse, naming the container/codec pair and suggesting --recode-audio=auto or a different container.

Touches CLI merge, the desktop IPC contract, and config.toml parity (#540/#583 are the precedent for that kind of change).

Acceptance

• Explicit --recode-audio=copy into a container that cannot carry the source codec refuses, naming both.
• The default (unspecified) path still re-encodes and warns — no regression to fix(postprocess): convert audio-only sources instead of demanding a video stream (#637) #644's matrix.
• A test distinguishes the two, failing against today's code where both are RecodeAudioMode::Copy.
• config.toml / IPC round-trip unchanged for an unspecified value.

Refs #637, #644

[crippledgeek]

Scope correction after tracing the actual call graph — this is much smaller than the issue body claims.

I wrote that it "touches CLI merge, the desktop IPC contract, and config.toml parity". Wrong: every layer above PostProcess already carries Option.

layer	type	preserves specified-ness?
Args::recode_audio (rdlp-cli/src/args.rs:351)	Option<String>	✅
rdlp-api DownloadRequest (request.rs:219)	Option<RecodeAudioMode>	✅
desktop IPC (src-tauri/src/commands/download.rs:98)	Option<RecodeAudioMode>	✅
desktop TS (src/types/index.ts:320)	RecodeAudioMode | null	✅
PostProcess::recode_audio (rdlp-types/src/postprocess.rs:174)	RecodeAudioMode	❌ collapses here

Both merge sites already assign conditionally:

// rdlp-cli/src/config.rs:325
if let Some(recode_audio) = &args.recode_audio {
    config.postprocess.recode_audio = RecodeAudioMode::from(recode_audio.as_str());
}
// rdlp-api/src/merge/mod.rs:147
if let Some(ref v) = self.recode_audio { config.postprocess.recode_audio = v.clone(); }

So the information is carried intact all the way down and thrown away at the last field. The fix is PostProcess::recode_audio: Option<RecodeAudioMode> plus the two unwrap_or_default() reads — not a cross-layer migration.

This is #540's bug, one layer lower

args.rs:344 documents the identical failure and its remedy:

Deliberately no clap default_value: absent must mean "not specified on the command line" so a recode_audio set in the config file survives. A default made that indistinguishable from an explicit copy, and the unconditional assignment downstream then discarded the config value on every run (#540).

#540 removed a default_value because it made absent indistinguishable from explicit copy. RecodeAudioMode's #[default] Copy on a non-optional field does exactly the same thing one layer down. The precedent for the remedy is already in-tree.

One nuance for the desktop

DownloadConfig.tsx:110 initialises the form with recodeAudioMode: "copy", so the desktop sends Some(Copy) whenever the user leaves the control alone. That is defensible — the user is looking at a control that says "copy" — but it means desktop users would get the refusal where CLI users who typed nothing would not. Worth deciding explicitly when implementing: either treat the desktop's default selection as explicit (simplest, and arguably honest), or add a null option to the control.

Refs #540, #637, #644