To remux an MKV file to MP4 without re-encoding, use FFmpeg with -c copy to copy the existing encoded streams into a new container. This works only for streams the MP4 muxer can carry; it does not make every MKV track compatible.
A remuxed MP4 is still a file, not a live broadcast. If you want to send that video to YouTube Live, an encoder or playout tool must read it and send a live feed using YouTube’s current settings.
Remuxing versus re-encoding
A media file has a container and one or more encoded streams. MKV and MP4 are containers: they organise video, audio, subtitles, and metadata, while codecs such as H.264 and AAC describe how particular streams are encoded. Remuxing changes the container while copying the encoded streams. Re-encoding decodes and encodes at least one stream again.
The distinction matters when you are preparing a file for an editor, player, upload workflow, or streaming tool that expects MP4. If the existing video and audio streams are suitable for MP4, remuxing can change the packaging without asking an encoder to recompress them. With FFmpeg, -c copy is the instruction that selects stream copy rather than an audio or video encoder.
Stream copy does not repair a codec that the intended player or destination cannot use. It also does not guarantee that every item in the MKV survives into the MP4. Container support, track selection, metadata, and the capabilities of your installed FFmpeg build all matter. The FFmpeg documentation describes stream copying and gives an MKV-to-MP4 example; check its current guidance alongside the error output from your own command.
If you are unsure which conversion you need, separate the question into two parts: do the streams work in the intended destination, and does that destination accept the existing container? A remux addresses the second part only. When the streams themselves are unsuitable, you may need to select different tracks or re-encode the affected stream.
Check whether the streams fit MP4
Before changing the container, find out what the MKV contains. A file can hold multiple video or audio tracks, subtitle tracks, chapters, or other data. For a devotional recording, for example, it might have a main video, a second audio language, and subtitle tracks that your intended MP4 workflow does not need.
FFmpeg’s ffprobe can report stream indexes, codec names, track types, and available metadata. Run it on the input file, then read the output before choosing what to include:
ffprobe input.mkv
The output is more useful if you know what you intend to keep. Identify the video track, the audio track you want, and any subtitles or additional audio that are genuinely needed. A file with several language tracks does not necessarily need all of them in a single output. Track indexes and language tags help you avoid keeping the wrong audio or relying on a default track you have not checked.
Do not infer compatibility just from the .mkv extension or a media player opening the source successfully. A player may support a combination the MP4 muxer does not accept. Likewise, a file called MP4 is not automatically suitable for every playback or live-ingest workflow: those workflows have their own codec and configuration requirements.
If the file is important, preserve the original and work on a copy. That gives you a straightforward way back if the chosen tracks are wrong or the output does not behave as expected. For a long source, a short representative sample can help you inspect track choices first, but it should not be treated as proof that every part or track in the full file will behave identically.
This is also a useful point to consider file handling separately from format conversion. The guide to uploading large video files for a YouTube 24/7 stream covers a different problem: moving a finished file into the workflow. Remuxing changes its container; it does not make a large upload finish sooner by itself.
Run FFmpeg with stream copy
For a first attempt that includes all input streams, use:
ffmpeg -i input.mkv -map 0 -c copy output.mp4
Replace input.mkv and output.mp4 with your actual file names. The command asks FFmpeg to read the MKV, map its streams into the output, copy them without encoding, and write an MP4. If the output file already exists, FFmpeg may ask whether to overwrite it; use a new name when you want to keep an earlier result.
The important option is -c copy. It applies stream copy, so FFmpeg does not decode and re-encode the audio or video. There is no quality setting to tune for those copied streams, because they are not being recompressed. The operation may take less processing than a full encode, but the time depends on the file and storage, so do not plan around a guaranteed duration.
The second important option is -map 0, which asks FFmpeg to include all streams from the input. It is convenient when you want every track and the muxer supports them. It is not a promise that all tracks in any MKV can be written to MP4. If FFmpeg reports a muxing or unsupported-stream error, inspect the reported stream and narrow the mapping rather than assuming that re-encoding everything is the only fix.
Once the command finishes, verify the output rather than relying only on a successful exit. Confirm that the file exists, that its duration is plausible, and that the intended video and audio play. Check track selection too, especially if the source has multiple audio languages or subtitles. This is a verification procedure, not a claim that a conversion has been tested here.
If you prefer a graphical workflow, a media utility may expose similar choices, but confirm that its mode is a remux or stream copy rather than a default transcode. Software labels vary, and a button called “convert” does not tell you whether the audio or video will be encoded again. FFmpeg makes the relevant choice visible in the command.
Understand what -map 0 includes
In FFmpeg, -map controls which input streams are sent to the output. The 0 refers to the first input file in this command. Consequently, -map 0 requests every stream from that input, not only the first video and first audio track. That can preserve useful alternatives, but it can also bring along tracks the MP4 muxer cannot accept.
If your intended output needs only the first video and first audio stream, use explicit mapping instead:
ffmpeg -i input.mkv -map 0:v:0 -map 0:a:0? -c copy output.mp4
Here 0:v:0 means the first video stream from the first input, and 0:a:0? means the first audio stream if one is present. The question mark makes that audio mapping optional, so the command can still proceed if the file has no audio stream. This example does not select subtitles or additional audio tracks; add them only after confirming that they are wanted and accepted by the output format.
Explicit mapping helps when a source has several tracks and you want a predictable output. For instance, if a recording includes a commentary track after the main audio, selecting the first audio track may be right only if you have checked the stream order. Probe the file and confirm what each track contains rather than treating “first” as synonymous with “main”.
Mapping is not a codec conversion. If you map a video or audio stream that the MP4 muxer cannot write, -c copy still asks FFmpeg to copy it. Choosing a compatible track may solve the problem; changing the container alone cannot alter the stream’s encoding. If you need a broader walkthrough of continuous playback choices, the article on VLC playlist repeat for a 24/7 YouTube music radio stream discusses a different part of the workflow: how to play media continuously, rather than how to package a source file.
Troubleshoot unsupported streams
When FFmpeg stops with an error about an unsupported codec, tag, or stream type, treat that message as evidence about the output path. Read which stream it names and compare that with the results from ffprobe. A source can be playable in one application yet fail to mux as MP4 because the application and muxer do not have the same support.
First try mapping only the tracks you actually need, using explicit selectors. If the error names a subtitle or data stream that is not required, omitting it may be enough. If it names an extra audio or video track, check whether another compatible track is available. This keeps the operation as a remux for the streams that remain; it does not require re-encoding them.
If the video or audio stream you need is itself incompatible with the MP4 output or the intended playback path, stream copy cannot change its codec. At that point, either keep a format and workflow that accepts the existing stream or re-encode the affected stream. Re-encoding is a different operation: it decodes and encodes again, so you must choose an encoder and settings appropriate to your use. Avoid silently converting the whole file when only one unnecessary track caused the failure.
Subtitles need particular care. Subtitle formats do not all have the same support across containers and playback tools, and a subtitle track may be omitted or handled differently in the output. If subtitles are essential, check whether the target accepts the particular subtitle format before deciding to discard or convert it. The same principle applies to chapters and metadata: verify what matters to your use instead of assuming that a container change preserves every non-audio/video element unchanged.
After adjusting the mapping, write to a fresh output name and inspect it again. A command that completes is only the beginning of verification. Play the relevant portions, check the chosen audio, and confirm that the output has the tracks you expected. If a local FFmpeg build reports a limitation, consult its current documentation and the exact message rather than applying a generic command that may not match your file.
A file is not a live feed
An MP4 is a stored media file. A YouTube Live broadcast is a feed sent from an encoder to YouTube using the stream configuration supplied through Live Control Room. Remuxing can prepare a file for a tool that prefers MP4, but the remux command does not connect to YouTube, transmit video in real time, or create a live event.
YouTube’s live encoder settings describe the live workflow, including supported protocols and codec guidance, audio settings, bitrate mode, and keyframe recommendations. The right settings depend on the resolution and frame rate you intend to send, so consult the current table rather than applying a single bitrate to every stream. YouTube’s recommended upload encoding settings are for uploaded files. They discuss MP4 and file-oriented guidance such as H.264 and Fast Start, but those upload recommendations are not a substitute for the live encoder settings.
The distinction can be useful if you run a long-running channel from a prepared video. Your file may be an input to a playout or encoding tool, but that tool still needs to read the media and send an accepted live feed. Whether it can read MKV or requires MP4 depends on that tool; the YouTube documentation does not say every live streamer must remux to MP4. For an overview of software roles, see OBS versus FFmpeg for a 24/7 kids’ video stream.
Before going live, obtain the stream URL and key from Live Control Room and enter them in the encoder you have chosen. Treat the key like a password. YouTube recommends testing before the event and monitoring stream health and messages; a prepared MP4 is not a substitute for checking what the encoder is actually sending. Its guidance on creating a live stream with an encoder describes the setup path. Check current official instructions before streaming because platform guidance can change.
For a channel that repeats an existing file, the practical choice is therefore two separate decisions: first, whether a remux is useful for the file-ingest step; second, how to keep an encoder or playout process sending a live feed. If operating your own computer overnight is the part you want to avoid, StreamNeo turns an uploaded video into a YouTube live stream, so you can upload the file and provide the stream key without leaving your computer running. It does not change the fact that you should prepare a compatible source and verify your live setup.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
How do I convert MKV to MP4 without re-encoding?
Use FFmpeg with -c copy, for example ffmpeg -i input.mkv -map 0 -c copy output.mp4. This copies streams rather than re-encoding them, but -map 0 can include tracks the MP4 muxer does not support. If that happens, inspect the file and map only the compatible tracks you need.
Can I remux an MKV file for YouTube Live?
You can remux a file if that helps the encoder or playout tool you use accept it, but the result remains a media file. A live encoder must send a feed to YouTube using its current live configuration. Check YouTube’s live guidance and your chosen tool’s file support rather than assuming MP4 is required.
Why does FFmpeg say the codec is not supported in MP4?
The stream may be playable in MKV but unsupported by the MP4 muxer in your FFmpeg build. Use ffprobe to identify the named stream, then omit it if it is not needed or choose a compatible track. If the stream you need cannot be copied into MP4, you may have to choose a different workflow or re-encode that stream.
Does -c copy preserve the whole MKV exactly?
It copies the encoded streams selected for output; it does not re-encode the audio or video. However, the output may not include every track or preserve all container-specific metadata, subtitles, or chapters in the same way. Check the finished MP4 for the tracks and behaviour you actually need.