How to Fix a Linux Driver Cause a Multiple Definition Error for My Firmware Array?

When working with Linux drivers, firmware arrays, or system commands, one of the most common problems I’ve run into is multiple definition errors or command misinterpretation. This usually happens because of how the compiler or runtime interprets certain special characters like the pipe symbol (|).

Recently, I had to debug this exact issue when I tried running an ffmpeg command inside Java. It threw me off at first, but step by step I figured it out. Let me walk you through what happened.

First Attempt The Problematic Code

I started with this piece of code, thinking it would just work:

public class StreamTest {
    public static void main(String[] args) {
        String command = "ffmpeg -i rtmp://192.168.1.112/garage/stream26g -f mpegts -acodec libmp3lame "
                + "-ar 48000 -ab 64000 -s 480x320 -r 30 -vcodec libx264 -b 544k -flags +loop -cmp +chroma "
                + "-partitions +parti4x4+partp8x8+partb8x8 -subq 5 -trellis 2 -refs 0 -coder 0 -me_range 16 "
                + "-keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -bt 200k -maxrate 544k -bufsize 544k "
                + "-rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 30 -qdiff 4 -level 30 -aspect 480:320 "
                + "-g 30 -async 2 - | vod - 10 stream/stream26g/sample stream/stream26g/stream.m3u8 "
                + "http://www.tshizerbia.com//video/ 5";

        try {
            Process p = Runtime.getRuntime().exec(command);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

The Error

When I ran it, this was the output:

Unable to find a suitable output format for '|'

At first, I thought maybe escaping the | would help. So I tried with \\|, but then the error simply changed to:

Unable to find a suitable output format for '\|'

Clearly, something was off.

Why Does This Error Happen?

Here’s what I figured out:

1. Java doesn’t automatically invoke a shell.
   The Runtime.exec() method doesn’t know what pipes (|), redirection (>), or backgrounding (&) mean. These aren’t regular arguments they’re shell features.
2. ffmpeg is being called directly.
   Because Java passes the command directly to ffmpeg, the | is treated as a literal string, not a pipe. Since ffmpeg has no idea what | is supposed to do, it fails.

In Linux, the | operator is always handled by the shell (bash or sh), not by the program itself.

Fix Use a Shell to Run the Command

The fix was straightforward once I realized what was happening: I needed to explicitly invoke the shell so that it could interpret the pipe.

Here’s the corrected version:

public class StreamTestFixed {
    public static void main(String[] args) {
        String command = "ffmpeg -i rtmp://192.168.1.112/garage/stream26g -f mpegts -acodec libmp3lame "
                + "-ar 48000 -ab 64000 -s 480x320 -r 30 -vcodec libx264 -b 544k -flags +loop -cmp +chroma "
                + "-partitions +parti4x4+partp8x8+partb8x8 -subq 5 -trellis 2 -refs 0 -coder 0 -me_range 16 "
                + "-keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -bt 200k -maxrate 544k -bufsize 544k "
                + "-rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 30 -qdiff 4 -level 30 -aspect 480:320 "
                + "-g 30 -async 2 - | vod - 10 stream/stream26g/sample stream/stream26g/stream.m3u8 "
                + "http://www.tshizerbia.com//video/ 5";

        try {
            ProcessBuilder builder = new ProcessBuilder("/bin/sh", "-c", command);
            builder.inheritIO(); // show logs in console
            Process p = builder.start();
            p.waitFor();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Now the shell (/bin/sh) runs the command and interprets the | correctly.

Extra Practice Functionality

Of course, I didn’t stop there. I wanted this to be more useful and flexible. So I added:

• Capturing standard output and error streams – so I could debug easily.
• Exit status checking – so I’d know if the command succeeded or failed.
• Dynamic arguments – so I could pass in a stream URL without editing the code every time.

Here’s the improved version:

import java.io.*;

public class StreamPractice {
    public static void main(String[] args) {
        // Dynamic input: use provided argument or fallback
        String inputStream = (args.length > 0) ? args[0] : "rtmp://192.168.1.112/garage/stream26g";

        String command = "ffmpeg -i " + inputStream + " -f mpegts -acodec libmp3lame "
                + "-ar 48000 -ab 64000 -s 480x320 -r 30 -vcodec libx264 -b 544k -flags +loop -cmp +chroma "
                + "-partitions +parti4x4+partp8x8+partb8x8 -subq 5 -trellis 2 -refs 0 -coder 0 -me_range 16 "
                + "-keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -bt 200k -maxrate 544k -bufsize 544k "
                + "-rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 30 -qdiff 4 -level 30 -aspect 480:320 "
                + "-g 30 -async 2 - | vod - 10 stream/stream26g/sample stream/stream26g/stream.m3u8 "
                + "http://www.tshizerbia.com//video/ 5";

        try {
            ProcessBuilder builder = new ProcessBuilder("/bin/sh", "-c", command);
            Process process = builder.start();

            // Read stdout
            BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream()));
            String line;
            while ((line = reader.readLine()) != null) {
                System.out.println("[OUTPUT] " + line);
            }

            // Read stderr
            BufferedReader errorReader = new BufferedReader(new InputStreamReader(process.getErrorStream()));
            while ((line = errorReader.readLine()) != null) {
                System.err.println("[ERROR] " + line);
            }

            int exitCode = process.waitFor();
            System.out.println("Process finished with exit code: " + exitCode);

        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Final Thought

In the end, fixing this issue taught me that many errors aren’t as complicated as they first seem they’re often just about understanding the environment. By letting the shell interpret the command and adding better error handling, I turned a frustrating bug into a learning moment. Now I have a cleaner, more flexible solution I can reuse for future projects.