Incompatible with ffmpeg 7

[avibrazil]

My code used to work flawlessly on Fedora 40 with its ffmpeg 6. Now, migrated to Fedora 42 and ffmpeg 7 and command line generated by ffmpeg-python breaks ffmpeg.

This is the command line generated:

ffmpeg -i input.MOV -i input.srt -map 0 -map 1 -acodec copy -map -0:d -map_metadata 0 -metadata:s:s:0 "title=Wall clock" -metadata:s:v rotate=0 -movflags faststart+use_metadata_tags -scodec mov_text -tag:s:s:0 tx3g -vcodec copy output.mov -hide_banner

And this it the ffmpeg error:

Stream type specified multiple times
Error parsing options for output file output.mov.
Error opening output files: Invalid argument

[gsauthof]

Without also posting a minimal working example that compiles to your command line I'm afraid nobody can really help you with this.

[lucemia]

This isn't really an ffmpeg 7 incompatibility in ffmpeg-python — there's a malformed stream specifier in the generated command that older ffmpeg tolerated and 7 rejects.

Compare these two arguments from your output:

-metadata:s:s:0 "title=Wall clock"   # valid
-tag:s:s:0 tx3g                      # invalid

They look symmetric but they aren't. -metadata takes a metadata specifier, which has the form s[:stream_spec] — so s:s:0 parses as "stream metadata" + stream spec s:0 (subtitle stream 0). Correct.

-tag takes a stream specifier directly, so s:s:0 gives it s (subtitle) followed by s:0 (subtitle stream 0) — the type twice. Hence exactly the error you get:

Stream type specified multiple times

The fix is dropping one s:

-tag:s:0 tx3g

so whichever kwarg produces tag:s:s:0 in your code should be tag:s:0.

Reproduced in isolation, on ffmpeg 8.1:

$ ffmpeg -f lavfi -i "color=c=black:s=64x64:d=0.1" -tag:s:s:0 tx3g -y out.mp4
Stream type specified multiple times
Error parsing options for output file out.mp4.
Error opening output files: Invalid argument

$ ffmpeg -f lavfi -i "color=c=black:s=64x64:d=0.1" -tag:s:0 tx3g -y out.mp4
# accepted

which is your error verbatim. Nothing else in that command line looks wrong to me. Going by your report, ffmpeg 6 accepted the malformed form and 7 doesn't — I haven't tested 6 myself to confirm where it tightened.

---

Separately, on the "incompatible with ffmpeg 7" framing: this repo's master has had no commits since July 2022 and ~480 open issues, so genuine version incompatibilities are unlikely to be addressed here. I maintain typed-ffmpeg, which generates its bindings per FFmpeg major by introspecting the actual binary, and ships separate packages for 5 through 9 — so filters and options that changed between versions are reflected in the API and in your type checker.

Being precise about what that would and wouldn't have done here: output() takes typed keyword arguments rather than **kwargs, so tag:s:s:0 raises TypeError instead of reaching ffmpeg — but it also has an extra_options passthrough, and putting the same malformed specifier through that produces the identical broken command. So it would have caught this on the ordinary path, not universally.

[avibrazil]

@lucemia thank you very much for the detailed analysis and explanation.
I'll check that on my next iteration with the software I was using that generated this error and eventually submit a patch to that project.

[lucemia]

Glad it helped. One thing worth checking when you patch it: the likely root cause is that the generator prefixes s: onto the specifier for every per-stream option, and only -metadata / -map_metadata actually want that.

ffmpeg has two similar-looking grammars:

• metadata specifier — g, c:N, p:N, or s:<stream_spec>. Used only by -metadata and -map_metadata. The leading s: means "this metadata belongs to a stream", and a stream specifier follows it.
• stream specifier — <index> or <type>[:index], e.g. 0, v, s:0. Used by everything else per-stream: -tag, -c/-codec, -b, -q, -filter, -disposition.

So for subtitle stream 0:

-metadata:s:s:0 title=...   # metadata spec "s:" + stream spec "s:0"
-tag:s:0 tx3g               # stream spec only — no "s:" prefix
-disposition:s:0 default
-c:s mov_text

If there's a single code path emitting f"{opt}:s:{stream_spec}", -tag won't be the only casualty. Same error on ffmpeg 8 for the other doubled forms:

$ ffmpeg -f lavfi -i "color=c=black:s=64x64:d=0.1" -disposition:s:s:0 default -y out.mp4
Stream type specified multiple times

$ ffmpeg -f lavfi -i "color=c=black:s=64x64:d=0.1" -b:s:v:0 1000k -y out.mp4
Stream type specified multiple times

Grepping for that s: prefix and restricting it to the two metadata options is probably the whole patch.