- Confirm whether the output contains video before changing HandBrake settings.
- Test H.264 MP4 to isolate codec, bit-depth, and device compatibility.
- Use HandBrake's Activity Log to identify incomplete or failed encodes.
- Confirm the Symptom With a Small Test Encode or Preview
- Check the HandBrake Settings Directly Related to This Problem
- Check Source, Destination, System, and Track Factors
- Use the Activity Log to Separate Guesswork From Evidence
- Run a Clean Temporary Encode With Minimal Settings
- Quick Fix Checklist
- Frequently Asked Questions
You finish a HandBrake conversion, open the output file, and hear the audio normally, but the picture is black, blank, frozen, or replaced by an unsupported-video message. This HandBrake audio only no video symptom does not always mean the video was lost during conversion. The usual causes are an unsupported video codec, a 10-bit or HDR playback limitation, an unsuitable container, an incomplete encode, a hardware-encoder problem, or a player that cannot decode the video stream. The steps below help you determine whether the output contains video, identify where the failure occurred, and create a compatible replacement without changing unrelated settings.

Start with free Canva bundles
Browse the freebies page to claim ready-to-use Canva bundles, then get 25% off your first premium bundle after you sign up.
Free to claim. Canva-ready. Instant access.
1. Confirm the Symptom With a Small Test Encode or Preview
First, separate an encoding problem from a playback problem. An output file can contain a valid video stream even when one application plays only its audio. Changing multiple HandBrake settings before making that distinction can hide the real cause.
1.1 Test the File in VLC and on the Target Device
Open the output in VLC media player, then test it in the application or device where you originally noticed the problem. VLC includes support for many codecs and containers that built-in players, televisions, browsers, editing programs, and older mobile devices may not support.
- If VLC shows video and plays audio, HandBrake probably created a usable file. The original player or device likely lacks support for the selected codec, bit depth, profile, level, HDR format, or container.
- If VLC also plays only audio, inspect the file for a video stream and review the HandBrake Activity Log.
- If neither audio nor video plays correctly, the file may be incomplete, damaged, or written to an unreliable destination.
When VLC displays the complete video without corruption, stop changing source, audio, and subtitle settings. Concentrate on compatibility with the target player instead.
1.2 Verify That a Video Stream Exists With MediaInfo
Open the output file in MediaInfo and use a view that shows separate General, Video, and Audio sections. A normal HandBrake output should contain a Video section naming a format such as AVC, also called H.264, HEVC, also called H.265, or AV1. It should also report dimensions, frame rate, duration, and bit rate where available.
If MediaInfo shows a video stream, the picture is present in the file. Playback compatibility or decoding is the more likely issue. If it shows only an audio stream, confirm that you selected the correct output file and examine the Activity Log for an aborted encode, source-reading failure, or muxing problem.
Success at this stage means you know whether the file actually contains video. Once a valid video stream is confirmed, do not repeatedly re-add audio tracks or change subtitle settings unless the log identifies them as a problem.
1.3 Create a Short Preview or Range-Limited Encode
Load the same source in HandBrake and encode a short chapter, a brief seconds range, or a preview using the same settings. Save it to a new local filename. This avoids waiting through a full movie or long recording while testing one change.
If the short test has the same audio-only behavior, the issue is reproducible and probably related to the chosen settings, source decoding, or playback environment. If the test works, the original job may have been interrupted, its destination may have failed, or the problematic source section may occur later.
2. Check the HandBrake Settings Directly Related to This Problem
Only a few settings directly determine whether a player can display HandBrake video. Review the preset, container, video encoder, bit depth, and hardware-encoding choice before adjusting quality or filters.
2.1 Compare Against a Safe H.264 Preset
For diagnosis, choose an official general-purpose preset that uses H.264 video and an MP4 container. Keep the preset defaults for the first short test. H.264 in MP4 is broadly supported across Windows, macOS, Linux, phones, televisions, web players, and common media applications, although compatibility still depends on the individual device.
Do not overwrite the failed output. Give the test file a simple new name and save it locally. If this H.264 comparison displays correctly on the target player, HandBrake is working and the earlier codec or profile was incompatible. You can stop troubleshooting the source and decide whether broad compatibility is more important than the efficiency or features of the previous encoder.
2.2 Check H.265 and AV1 Compatibility
H.265 can deliver efficient compression, but support varies by operating system, application, browser, hardware decoder, and device generation. Some players can parse an MP4 or MKV file and play its audio while failing to decode its H.265 video. AV1 support is also dependent on sufficiently recent software or hardware.
If your problematic output uses H.265 or AV1, update the target player's legitimate codec support where appropriate, use a capable player such as VLC, or re-encode a short test as H.264. A successful fix produces visible motion throughout the test on the actual target device, not merely in HandBrake's preview.
2.3 Review 10-Bit and HDR Choices
A 10-bit encoder creates video that requires 10-bit decoding support. An older graphics processor, television, streaming box, browser, editor, or system decoder may accept the audio while displaying black video or an unsupported-format warning. HDR introduces additional variables, including transfer characteristics, color metadata, display capabilities, and tone mapping.
Use MediaInfo to see whether the output is 10-bit and whether HDR metadata is present. As a diagnostic comparison, encode a short section with a standard 8-bit H.264 encoder. If that version works, the original 10-bit or HDR playback path was the issue. Stop changing audio settings because they cannot correct an unsupported video bit depth.
If preserving HDR is essential, verify that every part of the playback chain supports the chosen format, including the player, operating system, graphics hardware, cable path, and display. If compatibility matters more, create an SDR-compatible output with an appropriate workflow rather than assuming that changing the container will convert HDR to SDR.
2.4 Match the Container to the Target
MP4 and MKV are containers, not video codecs. A device may support H.264 in MP4 but reject the same general media combination in MKV. Conversely, MKV can accommodate track and subtitle combinations that are not suitable for every MP4 workflow.
Check the target device's documented format support, including both container and codec. For a broad diagnostic test, use MP4 with H.264 and a commonly supported audio format. If it works, stop changing settings and use that combination for the target, or test one advanced feature at a time.
3. Check Source, Destination, System, and Track Factors
If a conservative H.264 test also fails, examine the source, output location, operating system, graphics stack, and track selections. These checks are especially important when HandBrake appears not to be working across more than one player.
3.1 Make Sure the Encode Finished
An output file can exist before an encode is complete. Opening it while HandBrake is still writing, after a system sleep, following an application crash, or after a canceled queue job may produce incomplete or misleading playback.
Check the queue status and Activity Log for normal completion. Compare the output duration in MediaInfo with the expected duration. A tiny file, unexpectedly short duration, or missing final portion suggests that the job did not finish.
Success means the queue reports completion, the log reaches its normal finishing stage without a fatal error, and the output duration matches the selected range. If those conditions are met, stop investigating queue interruption.
3.2 Test a Local Destination
Save a new short output to an internal local drive with ample free space. Avoid a network share, cloud-synchronized folder, removable drive, unusually long path, or destination with uncertain permissions during diagnosis.
This test matters because a write interruption can leave a file that exists but is incomplete. It can also eliminate confusion caused by another application opening a partially synchronized copy. If the local output works, the destination or transfer process is the likely cause. Copy the completed file only after HandBrake finishes and verify the copied duration before deleting the local original.
3.3 Confirm That HandBrake Can Decode the Source
Scrub through the source preview and test multiple positions, particularly where the failed encode appeared to lose video. Then open the original in a reliable player. Screen recordings, variable-frame-rate phone videos, damaged camera files, interrupted downloads, and partially copied media can contain timestamp or decoding errors.
For DVDs and Blu-ray sources, work only with media you have the right to process. HandBrake is not a tool for circumventing copy protection. If HandBrake cannot scan or decode an authorized source correctly, obtain a clean, readable source through lawful means rather than attempting to force an encode from damaged or protected data.
If several positions preview normally and a short software-encoded test succeeds, the source is sufficiently readable for that range. If errors repeatedly occur at the same timestamp, the source likely needs repair, replacement, or lawful re-acquisition.
3.4 Compare Hardware and Software Encoders
Hardware encoders use graphics or media hardware to accelerate conversion. Driver problems, unsupported parameter combinations, or hardware-specific failures can occasionally produce unusable output or terminate a job. Names vary by platform and hardware, including Intel Quick Sync, NVIDIA NVENC, AMD hardware encoders, Apple VideoToolbox, and other supported interfaces.
Run a short comparison with the regular software H.264 encoder instead of a hardware encoder. If software H.264 works, update the operating system and graphics driver from the device or operating-system vendor, then retest hardware encoding with conservative defaults. On Linux, also consider whether the installed driver and permission configuration supports the selected hardware path.
Once software encoding produces a complete file that plays on the target, you have a dependable workaround. Stop altering filters, audio tracks, and subtitles. Continue hardware troubleshooting only if encoding speed is important enough to justify it.
3.5 Isolate Audio and Subtitle Track Complications
Audio or subtitle selections usually do not remove the video stream, but unusual track combinations can cause a device to reject or mishandle the overall file. Some televisions and older players have limited support for particular audio codecs, multiple tracks, embedded subtitle types, or advanced passthrough formats.
For a clean test, select one normal audio track, disable passthrough, and remove optional subtitle tracks. Do not burn subtitles during the first diagnostic encode unless they are required. If the simplified file works, add one desired track or subtitle feature per test until the incompatible element is identified.
If video remains visible after restoring the needed tracks, stop. There is no benefit in testing every possible track combination once the intended configuration works on the target.

4. Use the Activity Log to Separate Guesswork From Evidence
The Activity Log records source scanning, selected tracks, filters, encoder initialization, progress, warnings, errors, and job completion. It is more useful than repeatedly changing random options.
4.1 What to Look For in the Log
- Confirm that HandBrake detected a video title with plausible dimensions, duration, and frame rate.
- Verify that the chosen video encoder initialized instead of failing before frames were written.
- Look for repeated source read, decode, timestamp, hardware, muxing, or destination write errors.
- Check whether the job was canceled, crashed, or stopped because storage became unavailable.
- Confirm that the log reaches the end of the encode and reports job completion rather than only scan completion.
A warning is not automatically fatal. Focus on messages near the point where progress stopped and on repeated errors tied to video frames or output writing. Preserve the complete log before rerunning the job because a new encode may replace the most convenient evidence.
4.2 Interpret the Evidence Conservatively
If the log shows normal completion and MediaInfo shows a video stream, playback compatibility is the leading explanation. If the encoder fails to initialize, test software H.264. If source decoding repeatedly fails at one location, examine or replace the source. If writing fails, use a local destination with sufficient space and permissions.
Success means the evidence points to one category and your next test changes only that category. Stop making unrelated changes once a focused test resolves the symptom.
5. Run a Clean Temporary Encode With Minimal Settings
A controlled encode provides a reliable baseline when previous settings, imported presets, or queue jobs are difficult to interpret.
- Restart HandBrake and open the original source again.
- Select the correct title, chapter, or time range.
- Choose a general-purpose preset using H.264 and MP4.
- Use the regular software H.264 encoder for this comparison.
- Select one audio track with a broadly compatible encoded format rather than passthrough.
- Disable optional subtitle tracks and extra filters.
- Encode a short representative range to a new file on an internal drive.
- Wait for the queue and Activity Log to show completion.
- Inspect the file in MediaInfo, play it in VLC, and test it on the target device.
The baseline is successful when MediaInfo lists video and audio streams, VLC displays the picture, the target device plays the complete test, and the duration matches the chosen range. At that point, HandBrake and the source can produce functional video. Reintroduce H.265, AV1, 10-bit encoding, HDR handling, hardware encoding, subtitles, passthrough audio, or a different container one at a time.
Stop as soon as the output meets your real requirements. Troubleshooting is not improved by restoring an advanced option that the target cannot use.
6. Quick Fix Checklist
- Wait until the queue and Activity Log confirm that the encode completed.
- Open the output in VLC as well as the intended player or device.
- Use MediaInfo to confirm that the output contains a video stream.
- Compare the failed output with a short H.264, 8-bit, MP4 test.
- Replace H.265 or AV1 when the target does not support the selected codec.
- Test 8-bit output if 10-bit or HDR video displays as black.
- Use the container documented for the target device.
- Save the diagnostic output to a local drive with sufficient free space.
- Compare software H.264 against the selected hardware encoder.
- Use one encoded audio track and no optional subtitles during the baseline test.
- Review the Activity Log for decode, encoder, muxing, write, or completion errors.
- Change one variable at a time and stop when the target plays the file correctly.
7. Frequently Asked Questions
7.1 Why Does HandBrake Produce Sound but No Picture?
The most common explanation is that the output contains video encoded in a format the player cannot decode. H.265, AV1, 10-bit video, HDR formats, and certain codec-container combinations may work in one player but not another. An incomplete encode, source decoding failure, hardware-encoder issue, or interrupted destination write can produce similar symptoms. Test in VLC, inspect the video stream with MediaInfo, and read the Activity Log before re-encoding.
7.2 Does Audio-Only Playback Mean HandBrake Deleted the Video?
No. A player may recognize the container and audio stream while lacking support for the video stream. If MediaInfo lists a Video section and VLC displays it, the video was encoded. Use a more compatible player or create an H.264 MP4 output suitable for the target.
7.3 Should I Convert H.265 or AV1 to H.264?
Convert to H.264 when the target device or application cannot reliably decode the current format and broad compatibility is the priority. First encode a short H.264 comparison rather than converting the entire file. If that test works on the target, use it as your compatibility baseline.
7.4 Can a Wrong Audio Track Cause a Black Screen?
Usually not by itself. However, a target device may reject a file containing an unsupported audio passthrough format, unusual track arrangement, or unsupported subtitle type. A minimal test with one encoded audio track and no optional subtitles can identify that behavior. If the screen remains black, focus on the video codec, bit depth, container, and encode completion.
7.5 How Do I Know Whether the Encode Really Finished?
Check that the queue reports completion and the Activity Log reaches the end of the job without a fatal error or cancellation. Then compare the output duration with the selected source range. A file that merely exists is not proof that muxing and writing finished successfully.
7.6 What Is the Best Single Test When HandBrake Is Not Working?
Create a short local MP4 using a general-purpose H.264 preset, software encoding, one normal audio track, and no optional subtitles. Wait for confirmed completion, inspect it with MediaInfo, and play it in VLC and on the target device. This test separates source or application failure from advanced-setting and compatibility problems with minimal guesswork.