FFmpeg container error? It's the subtitle track: -c:s mov_text

Your command dies with Could not find tag for codec subrip in stream #2, codec not currently supported in container, then Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument. Nothing is wrong with your video or your audio. FFmpeg is telling you that MP4 has no shelf to put your subtitle track on, and it refuses to guess.

Quick answer: The FFmpeg error "codec not currently supported in container" means the output container has no tag for one of your streams, and on MP4 output that stream is almost always the subtitle track. Convert text subtitles with -c:s mov_text, burn bitmap subtitles (PGS, VobSub, DVB) into the picture with an overlay filter, or copy everything into an MKV instead. If you'd rather not hand-audit every input, FFmpeg Micro checks stream and container compatibility before the job runs, so a bad pairing comes back as a validation error on the request instead of a failed render: sign up free.

Why MP4 rejects a SubRip or ASS subtitle track

Containers aren't generic bags of streams. MP4, MOV, MKV, and WebM each carry a fixed lookup table mapping codecs to four-character tags, and if FFmpeg's muxer has no tag for your codec, it stops. The MP4 container has exactly one subtitle codec FFmpeg can mux into it: mov_text, the 3GPP timed text format. SubRip (subrip), Advanced SubStation Alpha (ass), WebVTT, and every bitmap subtitle format have no MP4 tag at all.

You can confirm this without reading any source. Run ffmpeg -h muxer=mp4 and the output includes Default subtitle codec: mov_text. Run it against Matroska and you get Default subtitle codec: ass. That single line is the whole story behind the error.

The trigger is usually -c copy. People run ffmpeg -i input.mkv -c copy output.mp4 expecting a fast remux, and -c copy applies to every stream, including the SubRip track they forgot was in there.

Read the stream number in the error before you change anything

FFmpeg names the exact stream it choked on, and that number is the fastest diagnosis you'll get. In Could not find tag for codec subrip in stream #2, stream 2 is the offender and subrip is the codec. If it says hdmv_pgs_subtitle, you're looking at Blu-ray bitmap subtitles and the fix is completely different from the text case.

The follow-up line, Could not write header for output file #0, is not a second problem. It's the consequence: the muxer aborted before writing the file header, so nothing was produced.

Detect the mismatch with ffprobe first

One ffprobe call tells you every stream and codec in the file, which is all you need to pick a fix:

ffprobe -v error -show_entries stream=index,codec_type,codec_name \
  -of csv=p=0 input.mkv

0,video,h264
1,audio,aac
2,subtitle,hdmv_pgs_subtitle
3,attachment,ttf

That output settles it in one look. Stream 2 is a bitmap format, so -c:s mov_text will never work on it, and stream 3 is an embedded font that MP4 also can't hold.

Here's the part that costs real money. FFmpeg validates codec and container pairing when it writes the output header, which happens before the first frame is encoded, so a single bad command fails in about a second. The damage shows up in pipelines: a two-step workflow that transcodes to an intermediate and then muxes subtitles at the end throws away the entire encode, and a batch loop over 200 files dies on the one file someone pulled from a Blu-ray rip. Gating on ffprobe is the cheap version of the check. Routing the job through the FFmpeg Micro API is the version where you don't write the gate yourself, because the compatibility check runs server side before any encoding starts and the job is rejected with a reason instead of burning compute.

Fix 1: convert text subtitles to mov_text

For SubRip, ASS, SSA, or WebVTT tracks going into MP4, name the subtitle codec explicitly and let FFmpeg transcode the subtitles while copying everything else:

ffmpeg -i input.mkv \
  -map 0:v -map 0:a -map 0:s \
  -c:v copy -c:a copy -c:s mov_text \
  -metadata:s:s:0 language=eng \
  output.mp4

The subtitle conversion is near-instant because it's text. The -metadata:s:s:0 language=eng flag matters more than it looks: without a language tag, QuickTime and the iOS player often list the track as "Unknown" and some players skip it entirely.

Expect to lose styling. mov_text carries plain timed text, so ASS karaoke effects, positioning overrides, fonts, and colors are dropped in the conversion. If the styling is the point, you want fix 2 or fix 3.

Fix 2: burn bitmap subtitles into the video

PGS, VobSub (dvd_subtitle), and DVB subtitles are images, not text, so there is no conversion path to mov_text at all. Try one and FFmpeg answers with Subtitle encoding currently only possible from text to text or bitmap to bitmap. The only way those subtitles reach an MP4 is drawn onto the video frames:

ffmpeg -i input.mkv \
  -filter_complex "[0:v][0:s:0]overlay" \
  -c:v libx264 -crf 20 -preset medium -c:a copy \
  output.mp4

The overlay filter takes the bitmap subtitle stream as its second input and composites it. This forces a full video re-encode, so a 90-minute film that would have remuxed in 20 seconds now takes as long as an H.264 encode of that film.

Text subtitles can be burned in too, using a different filter, when you want the ASS styling preserved as pixels:

ffmpeg -i input.mkv -vf "subtitles=input.mkv:si=0" -c:a copy output.mp4

Burn-in has its own failure modes around fonts and timing, which is a separate rabbit hole covered in the burn-in problems behind translated subtitles.

Fix 3: keep every subtitle and change the container

Matroska accepts SubRip, ASS, WebVTT, PGS, and VobSub as-is, so if the destination isn't a browser or an Apple device, the cheapest fix is to stop targeting MP4:

ffmpeg -i input.mkv -c copy output.mkv

That remuxes at disk speed with zero quality loss and zero subtitle degradation. The trade-off is real: Safari and the iOS Photos app won't play MKV, and most social platforms reject it on upload. Use MKV for archive and intermediate steps, MP4 for anything a browser or a phone touches.

If you don't need the subtitles in the output at all, -sn drops every subtitle stream and the error disappears.

The same error hits audio: PCM in MP4, Opus in MOV

Subtitles are the common case, but the muxer applies identical tag lookups to video and audio, which is why Could not find tag for codec pcm_s16le shows up when someone sends a WAV-audio capture into MP4. This table covers the pairings that actually break in practice.

Two rows deserve a note. PCM is fine in MOV and MKV and rejected by MP4, so -c:a aac or -c:a flac is the fix for a WAV-sourced track. Opus is fine in MP4 and rejected by MOV, which catches people producing QuickTime masters from WebM sources.

HEVC is the odd one out, because it gets a tag in MP4 but the wrong tag for Apple playback by default. That's a related failure with a one-flag fix, covered in the FFmpeg hvc1 tag fix.

Common pitfalls

Container and codec mismatches have a handful of edge cases that send people back to the same error after they thought they'd fixed it.

FAQ

What does "codec not currently supported in container" mean in FFmpeg?

The FFmpeg message "codec not currently supported in container" means the output format's muxer has no registered tag for one of the streams you asked it to write. FFmpeg names the codec and the stream index in the same line, and the failure happens at header-write time, before any frames are encoded.

Is `-c:s mov_text` lossy?

Converting subtitles with -c:s mov_text is lossless for the text and timing, and lossy for everything else. The 3GPP timed text format stores plain cues, so ASS and SSA styling, positioning, fonts, and colors are discarded during the conversion.

Can I put PGS subtitles in an MP4 file?

PGS subtitles cannot be muxed into an MP4 file in any form, because the MP4 container has no tag for bitmap subtitle streams. Your two options are burning them into the video frames with FFmpeg's overlay filter, which requires a video re-encode, or keeping the file in MKV where PGS is natively supported.

Why does FFmpeg say "Could not write header for output file"?

The "Could not write header for output file" line is a downstream symptom, not the cause. FFmpeg prints it right after the specific stream rejection (usually "codec not currently supported in container"), because the muxer aborted before it could write the file header. Fix the named stream and the header error goes away.

Should I use MP4 or MKV when a video has subtitles?

Use MKV when the file is an archive or an intermediate in your pipeline, since Matroska accepts SubRip, ASS, WebVTT, and bitmap subtitle formats with no conversion. Use MP4 with -c:s mov_text or burned-in subtitles when the file is going to a browser, an iPhone, or a social platform upload.

If your pipeline processes files you didn't create, you'll hit this error on whichever input someone pulled off a disc, and you'll hit it after the expensive part of the workflow. FFmpeg Micro runs the same operations as one API call with compatibility checked before the job starts, and the free tier is enough to test your worst input file: sign up free.