Your 100-Video Batch Failed at File 87. Why Start Over?

Picture this: you queue up 100 source videos, go make coffee, and come back to an error on file 87.

The first 86 outputs are fine. Yet your script wants to start from file 1 again.

That's not just an FFmpeg problem. It's a batch-workflow design problem.

Here are five practical ways to make batch video processing more reliable, reduce wasted time, and recover from failures without unnecessary repetition.

1. Make Each Video an Independent Job

A batch should be a collection of independent jobs, not one enormous success-or-failure command.

Every video should have its own processing status:

• Queued: Waiting to be processed.
• Running: Currently processing.
• Completed: Successfully processed and verified.
• Failed: An error occurred, but other jobs can continue.
• Needs Review: The result is uncertain after an interruption.

If video 87 fails, the system should preserve the work completed on videos 1–86 and report the failed file clearly.

A useful progress indicator should distinguish completed, failed, and remaining tasks.

Remember: 100% processed is not the same as 100% successful.

2. Protect Outputs From Interrupted Processing

Imagine FFmpeg crashes halfway through creating clip_087.mp4.

The output file may exist, but that doesn't guarantee it is playable.

A safer approach is:

1. Create a temporary output file.
2. Process the video into that temporary file.
3. Verify the expected audio and video streams.
4. Move the verified output to its final destination.
5. Record the result in the job log.

For example:

for job in pending_jobs:
    mark_running(job.id)

    temp = temporary_mp4_path(job.output)
    result = run_ffmpeg(
        job.source,
        temp,
        job.settings
    )

    if result.ok and expected_streams_present(temp):
        atomic_replace(temp, job.output)
        mark_done(job.id)
    else:
        mark_failed(job.id, result.error)

This is illustrative pseudocode, not a complete production-ready script.

FFprobe can help inspect media streams, but it does not guarantee that every frame decodes correctly. Higher-reliability workflows may also require decoding checks.

3. Resume Work Instead of Starting Over

Suppose your batch contains 100 videos.

After processing 86 videos, the application closes unexpectedly.

A reliable recovery system should determine:

• Which files were completed successfully?
• Which outputs are incomplete?
• Which tasks failed?
• Which settings were used?
• Which tasks still need processing?

A small job manifest can record the source identity, output destination, processing settings, and result.

However, simply skipping an existing output filename is not enough.

If the user changes the clip duration from 15 seconds to 8 seconds, an old output should not automatically be treated as valid.

Resume the same work only when its inputs, settings, and verified outputs still match.

4. Handle Different Failures Differently

Not every error should trigger the same retry strategy.

Corrupted or unsupported source video

Record the failure and continue processing other independent tasks.

Temporary file access error

A limited retry with a short delay may resolve the issue.

Insufficient disk space

Pause affected processing and notify the user. Repeated retries will not solve a full disk.

Incompatible audio streams

Check sample rates, channel layouts, codecs, and missing audio streams before attempting video merging.

Also, duration=N/A in FFprobe output does not automatically mean a file is invalid. Some files require additional stream inspection or decoding tests.

The goal is to diagnose problems before deciding whether to retry, skip, or stop.

5. Keep Video Slicing and Merging Separate

Batch slicing and batch merging solve different problems.

Video slicing divides source videos into shorter clips.

Video merging combines multiple clips into a single output video.

Merging can introduce additional compatibility requirements, particularly when source files use different codecs, resolutions, frame rates, or audio configurations.

A reliable workflow should identify whether an error happened during:

• Source media inspection
• Video decoding
• Clip generation
• Audio processing
• Final video merging

This makes troubleshooting significantly easier.

A Simple Reliability Test

Before trusting a batch video workflow, try these five tests:

1. Process several valid videos with one intentionally broken file in the middle.
2. Interrupt processing and check whether completed outputs remain intact.
3. Change the output settings and verify that old results are not incorrectly reused.
4. Test files with different audio configurations.
5. Review the final report for completed jobs, failures, and actual output locations.

A good batch-processing workflow is not one that never encounters errors.

It's one that fails clearly, preserves successful work, and recovers without wasting hours.

---

Why I'm Interested in This Problem

I'm working on ChanPilo, a Windows video-processing toolkit designed to simplify repetitive workflows for content creators.

The focus is on practical tasks such as batch video slicing, video merging, local processing, and organizing exported content.

Website: https://chanpilo.com/

The reliability techniques discussed here are general software design practices, not a claim that every recovery feature described above is already implemented in ChanPilo.

AI assistance was used to help edit this article.

Let's Discuss

For developers, video editors, and content creators:

What is the most frustrating problem you've experienced with batch video processing?

• Incompatible source files?
• Failed video exports?
• Audio synchronization issues?
• Having to restart an entire batch after one error?

I'd love to hear your experiences and how you've solved these problems.