I'm running native image and video commands from PowerShell 5.1 on Windows 11, and piping binary output from one program into another produces application-specific errors about invalid or corrupted pipe data. The same commands work correctly in PowerShell 7 and in Command Prompt. For example:
magick myphoto.jpg png:- | magick png:- myphoto.webp
ffmpeg -i myphoto.jpg -f webp pipe: | ffmpeg -f webp_pipe -i pipe: myphoto.png
I can work around the issue by invoking Command Prompt from my PowerShell script, but that feels awkward. Is there a way to make binary pipelines work directly in PowerShell 5.1 without installing PowerShell 7 on every machine?
2 Answers
This is a limitation of older PowerShell versions, not a problem with ImageMagick or FFmpeg. In PowerShell 5.1—and PowerShell versions through 7.3—the output from a native program is treated as text before being passed through the pipeline. That text is then converted back into bytes, which corrupts arbitrary binary data. Native binary-to-binary piping was properly supported starting with PowerShell 7.4.
For older versions, the practical options are to run the pipeline through another shell, such as `cmd /c "command1 | command2"`, or redirect the first program’s output to a file and use that file as the second program’s input. The file approach avoids corruption but sacrifices streaming and may require extra disk space.
So the important change in newer PowerShell is that native binary output can pass directly from one native process to the next, instead of being converted through PowerShell’s text pipeline first?
PowerShell 5.1 cannot safely pipe arbitrary binary stdout between native applications because of how it handles the stream. Running the pipeline in Command Prompt is a valid workaround, and upgrading to PowerShell 7.4 or newer is the cleanest solution if installation is possible. Another fallback is to use `Start-Process` with output and input redirection through a temporary file, although that no longer provides a streaming pipeline.
That explains the behavior perfectly. I already have a `cmd` workaround, so I’ll probably keep using it where PowerShell 7.4 isn’t available. I was surprised this limitation lasted for so long.