Why Does a Video Download Need Audio and Video Merging?

What Does “Audio and Video Merging” Mean?

When you watch a finished movie or online video, you normally experience two things at once:

picture + sound

It is easy to assume that both are always stored inside one simple file.

That is not necessarily how modern media delivery works.

A source may provide a video stream separately from its audio stream. The video stream contains the moving images. The audio stream contains the sound. A player or downloader then uses the two streams together.

A media container can hold one or more media streams along with metadata. The container and the codecs used by those streams are separate concepts. (MDN Media Container Formats)

When a downloader combines separate streams into one playable file, that operation is commonly described as muxing or, depending on the exact operation, remuxing.

The important part is this:

Merging media streams does not automatically mean the video is being compressed again.

That distinction explains why a downloader may show a processing stage even though the source video has already been downloaded.

Why Are Video and Audio Sometimes Separate?

Modern streaming systems often need flexibility.

A service may want to offer:

several video resolutions several video bitrates different audio languages different audio quality levels alternative audio descriptions multiple versions for different devices or network conditions

Keeping some of these tracks separately can make those combinations easier to deliver.

For example, adaptive streaming systems such as MPEG-DASH can provide separate video representations and an audio representation. MDN's DASH documentation shows an on-demand presentation containing multiple video representations alongside an audio representation. (MDN — Setting up adaptive streaming media sources)

Apple's HLS documentation likewise describes separate audio renditions associated with video variants and explicitly recommends delivering video and audio as separate streams in appropriate HLS workflows. (Apple HLS Authoring Specification)

The practical benefit is that a player can select the appropriate video and audio combination without the provider having to create a completely separate combined file for every possible combination.

Video-only streams

A video-only stream contains the picture track but does not contain an audio track.

Conceptually:

VIDEO

There may be several video-only representations of the same content:

lower resolution medium resolution high resolution different codecs different bitrates

A player can then select one appropriate representation.

Audio-only streams

An audio-only stream contains the sound track without the video.

Conceptually:

AUDIO

The source may provide one audio track or several.

For example, a service could have different language or quality choices.

Combined or progressive streams

A combined stream contains both video and audio in one media format.

Conceptually:

VIDEO + AUDIO

These are sometimes called progressive downloads because the media can be retrieved as a combined resource rather than requiring a separate video and audio selection.

But a combined format may not always be the highest-quality representation available.

That is one reason a downloader may encounter separate video and audio streams when the user asks for a higher-quality version.

Why Modern Streaming Systems Use Separate Media Streams

The reason is not simply “to make downloading harder.”

Separate media representations are useful for adaptive playback.

Suppose your connection is strong.

A player may select a higher-quality video stream.

If network conditions become worse, it can switch to a lower-quality video representation while continuing to use an appropriate audio track.

MDN explains that adaptive streaming uses multiple quality representations and that MPEG-DASH manifests describe available streams, their bandwidths, codecs, and media locations. (MDN — DASH Adaptive Streaming)

HLS works with a similar concept. Apple documents multiple video tiers and separately associated audio renditions, including alternative languages and other audio variants. (Apple — Common Media Application Format with HLS)

This architecture is useful during streaming because the player can make choices based on bandwidth, device capabilities, language, and other factors.

A downloader has to solve a different problem:

How do I turn the selected media streams into one usable file?

What Happens When You Download Separate Video and Audio?

When the source provides separate streams, the process generally looks like this:

Source streams

↓

Format selection

↓

Video stream + audio stream

↓

Download both

↓

Mux / merge

↓

Final media file

The exact implementation varies between software, platforms, and formats, but the concept is straightforward.

1. Source format detection

The downloader first needs to inspect the source.

It has to discover things such as:

which video streams exist which audio streams exist resolutions codecs containers bitrates file sizes when available whether video and audio are already combined

yt-dlp exposes media formats so applications can select between these kinds of representations. Its format-selection documentation includes separate bestvideo and bestaudio selections. (yt-dlp README)

1. Video stream selection

The downloader chooses a video representation appropriate to the user's requested quality.

For example, if the user asks for 1080p, the downloader may look for a suitable video stream whose height is 1080 pixels.

The actual codec and bitrate can still vary.

This is why “1080p” tells you the resolution, but not necessarily the complete characteristics of the underlying media stream.

1. Audio stream selection

If the selected video stream does not contain audio, the downloader also needs an audio stream.

yt-dlp supports the bestaudio concept specifically for selecting the best available audio-only stream. (yt-dlp README)

The downloader then has:

video

and:

audio

1. Downloading the streams

Those streams can then be retrieved separately.

The amount of data and time involved depends on the particular streams selected.

A high-resolution video stream plus a separate audio stream may therefore require the downloader to transfer more than one media resource.

1. Merging or muxing

Once both streams are available, a media-processing tool can place them into a suitable output container.

This is the point where muxing becomes important.

FFmpeg's official documentation describes muxers as components that take encoded media packets and write them into a specified output container. (FFmpeg Muxing Documentation)

The encoded video and audio can therefore remain encoded while the container is built around them.

1. Final file preparation

The system still needs to:

finalize the output container write required metadata/index information confirm the output exists make the file available to the user

This is why a download can appear to reach the end of its network transfer while the application still reports a processing stage.

Muxing vs Remuxing vs Re-Encoding

These words sound similar but describe different operations.

Muxing

Muxing means putting encoded media streams into a container.

Conceptually:

Encoded video + encoded audio → container

The streams already exist in encoded form.

The muxer writes them into the output structure along with the information needed to describe the media.

FFmpeg's muxing documentation describes this as writing encoded packets into a specified container format. (FFmpeg Muxing Documentation)

Remuxing

Remuxing is commonly used when media streams are moved or repackaged from one container structure to another without changing the underlying encoded media.

For example:

video/audio streams → Container A

becoming:

the same video/audio streams → Container B

when the streams are compatible with the destination.

The exact terminology varies somewhat depending on the workflow, but the important beginner-level idea is:

the media can be repackaged without necessarily being re-encoded.

Re-encoding

Re-encoding is different.

The media is decoded and encoded again.

Conceptually:

encoded video → decode → re-encode → new encoded video

The same can happen with audio.

Re-encoding may be necessary when:

the codec must change the stream parameters must change the destination cannot accept the original encoding filters or other transformations are required the output needs a completely different encoding

Because the media is encoded again, quality, file size, processing time, and CPU requirements can change.

FFmpeg documents transcoding as a process involving decoding and encoding, while stream copy avoids decoding and encoding the copied streams. (FFmpeg Documentation)

Why Merging Does Not Automatically Reduce Video Quality

Suppose the source gives you:

H.264 video

and:

AAC audio

and both are compatible with the output container.

A stream-copy merge can place those already-encoded streams into a final container without encoding the video again.

That is fundamentally different from compressing the video.

FFmpeg's -c copy behavior performs stream copying rather than decoding and re-encoding the streams. (FFmpeg Documentation)

However, it would be too broad to say that every merge is guaranteed to preserve quality.

If the workflow requires re-encoding one of the streams, then the resulting media can have different quality and file characteristics.

So the accurate rule is:

A compatible stream-copy merge generally does not recompress the copied audio/video streams; a re-encoding step can change them.

Why Merging Is Not the Same as Compressing a Video

Compression changes how much data is used to represent the media.

Merging solves a different problem:

How do I package the video and audio together?

Imagine you already have:

video.mp4-like video stream

and:

audio stream

Putting those together in a suitable container does not inherently make the video smaller.

The encoded video data can remain unchanged.

That is why you should not interpret:

Processing media…

as:

Compressing video…

They are not necessarily the same operation.

MediaFetches' normal managed video path uses FFmpeg with:

-c copy

along with:

-movflags +faststart

so the normal video merge path is designed around stream copying rather than ordinary video re-encoding.

Why a Downloaded Video Can Have No Sound

A silent video can happen for several reasons.

Audio stream unavailable

The source may provide a video representation without a usable audio track.

If no compatible audio stream is available, the final result may be video-only.

This is particularly plausible when dealing with separate adaptive-stream representations.

The selected stream contains video only

If software retrieves only the video representation and never adds an audio stream, the resulting file can be completely silent.

The picture can be perfectly normal.

The audio simply is not there.

Audio/video selection problem

The source may have audio and video available, but the selected combination may not be usable together.

For example, the downloader may need to choose a different audio representation or different video representation.

Processing or merge problem

The source streams may have been downloaded successfully, but the final merge can fail.

That changes the problem from:

source download

to:

media processing

Container compatibility issue

Not every container accepts every possible combination of encoded streams.

MDN documents different codec/container combinations and notes that browser support depends on both the container and codecs used inside it. (MDN Media Container Formats)

A stream can therefore exist and be valid while still not fitting the requested output container.

Source-specific extraction problem

The browser may be using a streaming architecture that does not map neatly onto a standalone downloadable file.

As a result, one specific source can fail even when other videos work.

How FFmpeg Helps Combine Video and Audio

FFmpeg is a media-processing toolkit.

For this particular job, the important concept is not all the things FFmpeg can do. It is that FFmpeg can:

read media streams inspect media formats mux streams into containers remux compatible streams re-encode when required perform other media-processing operations

FFmpeg's official documentation describes muxers as writing encoded packets into output containers and provides separate documentation for codec copy and transcoding behavior. (FFmpeg Muxing Documentation, FFmpeg Documentation)

That makes it a useful piece of a downloader's final processing stage.

You do not need to understand FFmpeg command-line syntax to understand what it is doing conceptually.

Think of it as the component that can turn:

video stream + audio stream

into:

one playable media file

when the selected streams and destination are compatible.

How MediaFetches Handles Audio and Video

The current MediaFetches project uses yt-dlp for source extraction and FFmpeg for media-processing tasks.

The exact workflow depends on what the source provides.

How source formats are detected

MediaFetches asks yt-dlp for source information and available formats.

The project then examines those formats to determine:

which video heights exist whether a video format already includes audio whether separate video/audio streams are available whether a usable quality option exists whether an estimated file size can be calculated

The quality ladder is based on the source's reported video heights rather than hardcoded format IDs.

How video and audio are selected

The current project distinguishes between progressive and separate-stream formats.

If a source has a video format at the requested height that already contains both video and audio, MediaFetches can use a selector based on that combined format.

Conceptually:

best combined video+audio format

If there is no combined format at that height, the project uses:

bestvideo[height=…]+bestaudio

That explicitly asks yt-dlp for a video stream and an audio stream.

yt-dlp documents this style of format selection and the requirement for FFmpeg when separate video and audio formats need to be merged. (yt-dlp README)

When separate streams are merged

When MediaFetches selects the separate-stream path, yt-dlp downloads the video and audio independently and the processing pipeline handles the merge.

The project requests:

MP4

as the preferred managed video output.

The normal processing arguments use:

-c copy

which means stream copying rather than ordinary re-encoding.

Why FFmpeg is involved

FFmpeg is needed for the cases where yt-dlp must combine separate streams or perform the final media-container processing.

The project resolves an FFmpeg binary either from an explicitly configured path, a bundled ffmpeg-static package, or a system installation when available.

That means FFmpeg is part of the actual MediaFetches server architecture rather than being something the user is expected to install just to use the website.

What +faststart does

MediaFetches also uses:

-movflags +faststart

for its normal managed MP4 video processing.

FFmpeg documents faststart as moving the MP4 moov atom/index toward the beginning of the file through an additional pass. This can improve the ability to begin playback before the entire file has arrived in certain delivery situations. (FFmpeg formats documentation)

This is another reason processing may continue after the underlying media download reaches completion.

What MediaFetches Does Not Expose

The current MediaFetches interface does not give users a professional-grade stream-selection panel.

Users cannot manually enter:

a codec a container a format ID a bitrate a custom FFmpeg command a video stream ID an audio stream ID an individual audio track

Instead, the user selects from the quality options that MediaFetches builds from the source information.

That keeps the interface understandable for ordinary users.

It also means that MediaFetches does not promise that users can manually force every possible source combination into MP4.

The source formats still determine what the processing pipeline can legitimately produce.

Why Processing Can Continue After the Download Reaches 100%

This is easier to understand once the pipeline is clear.

100% transferred

means:

the source-transfer stage has reached the end

It does not necessarily mean:

the finished file is ready for the browser to save

The system may still need to:

merge video and audio write container information run the FFmpeg post-processing step move MP4 indexing information for fast start confirm the final file exists remove leftover intermediate files

MediaFetches explicitly separates:

Downloading media…

from:

Processing media…

before reaching:

Ready to save

That distinction is part of the actual job lifecycle in the current project.

When a Merge Can Fail

A merge is not guaranteed simply because both streams exist.

Incompatible streams

The selected streams may not be compatible with the desired output container.

Missing audio

The source may not expose a usable audio representation.

Missing video

The requested quality may not expose a usable video stream.

Unsupported output/container combination

The selected codec combination may not fit the preferred output container.

In the MediaFetches implementation, the managed download code checks what file yt-dlp actually produced rather than assuming that .mp4 must exist. The project can therefore handle an edge case where the selected codecs cannot be placed into the preferred MP4 container and another output container is produced.

FFmpeg processing failure

Even when both source streams were retrieved, FFmpeg can still fail during the final processing stage.

That should be diagnosed as a processing problem, not automatically as a source-download problem.

The user-facing job system can report the job as failed, while the more detailed technical cause remains on the server side.

How to Troubleshoot a Video With Missing Audio

If your downloaded file has picture but no sound, work through the problem in this order.

Check the source

Play the original video normally.

If the original itself has no sound, the downloaded file is not the cause.

Check whether other videos work

If other downloads contain normal audio, the problem may be specific to the source or its available streams.

If every video loses audio, investigate the common processing path instead.

Try another available quality when appropriate

If the source exposes several quality choices and one version produces sound while another does not, the issue may be tied to a particular source representation.

This does not mean lower quality is inherently better.

It simply helps isolate the failing stream combination.

Distinguish transfer failure from processing failure

If the job never gets to a usable video file, the problem may be extraction or downloading.

If the source data appears to have completed and the job then enters:

Processing media…

the problem may be in the merge or final output stage.

Know when the problem is source-side

If one particular video repeatedly fails while unrelated public videos work, the source's media structure or availability becomes a stronger possibility.

Changing your device or browser repeatedly may not solve a source-specific media problem.

Common Questions Why is my downloaded video silent?

A common reason is that the downloaded result contains a video stream without a corresponding audio stream.

That can happen when the source provides separate streams and the audio was not selected or could not be merged into the final output.

Why can a 1080p video be video-only?

Resolution and audio presence are separate properties.

A 1080p stream can contain only video.

Another 1080p representation can contain both video and audio.

The resolution number does not tell you whether an audio track is included.

Does merging reduce quality?

Not necessarily.

When compatible encoded streams are muxed using stream copying, the video and audio are not being recompressed simply because they are being placed into a container.

If re-encoding is required, however, the resulting media can have different quality and file characteristics.

Does merging re-encode the video?

Not necessarily.

In the normal MediaFetches managed video path, FFmpeg is invoked with -c copy, which is stream copying rather than ordinary video re-encoding.

What is FFmpeg doing during a video download?

Depending on the source, FFmpeg can be involved in combining separate video and audio streams and preparing the final container.

It may also perform other post-processing when required.

In MediaFetches, it is part of the server-side media pipeline.

Why does processing continue after 100%?

Because 100% can represent completion of the source-transfer stage.

The application may still need to merge streams, finalize the container, apply the MP4 faststart processing, and prepare the finished file.

Can MediaFetches let me choose the audio and video streams manually?

No.

The current interface does not provide manual stream IDs, codec selection, bitrate selection, or custom format expressions.

MediaFetches selects suitable formats from the source information it receives.

Sources and references

• FFmpeg documentation

Related MediaFetches guides

For related guidance, see MP4 vs WebM guide and audio format comparison.

Final Takeaway

A modern video download is not always a single file waiting on a server.

Depending on the source, you may have:

video stream

plus:

audio stream

and the downloader has to turn those streams into a usable final media file.

The most important terms are:

Video-only stream — picture without audio.

Audio-only stream — sound without picture.

Combined/progressive stream — video and audio already together.

Muxing — putting encoded streams into a container.

Remuxing — repackaging compatible streams without necessarily re-encoding them.

Re-encoding — decoding and encoding media again.

FFmpeg is useful because it can perform the muxing, remuxing, and other media-processing work required by a downloader. yt-dlp handles source extraction and format selection, while MediaFetches coordinates those pieces into the final download workflow. (yt-dlp README, FFmpeg Documentation)

For MediaFetches users, the practical flow is:

Source formats → quality selection → video/audio selection → download → merge/process → finished file

So when you see Processing media…, that does not automatically mean something went wrong.

And when a video arrives without sound, the problem is not necessarily your phone, speakers, or media player.

The audio stream may simply not have been included successfully.

The key idea is simple: downloading the picture and producing a complete video are sometimes two separate jobs. MediaFetches uses yt-dlp to obtain the appropriate source streams and FFmpeg to prepare them into the final media file when needed.