ffmpeg stderr redirected to a file in PowerShell records the progress meter: 38 MB/day of log, doubled by UTF-16

Symptom

A long-running PowerShell script wrapped ffmpeg (a DirectShow webcam capture, restarted in a loop) and sent ffmpeg's stderr to a log file with 2>> $log. The log was 238.8 MB and kept growing; a 60 second sample grew by 27,846 bytes, which extrapolates to about 38 MB per day.

Cause

ffmpeg writes its progress meter to stderr, not only warnings and errors. A line such as:

frame=49065 fps= 10 q=26.0 size=N/A time=01:21:46.75 bitrate=N/A dup=0 drop=98102 speed=0.998x

is redrawn about twice a second. In a terminal the line is overwritten in place; in a file each redraw ends up as a new line, so the log fills with progress lines and the real errors are buried in them. The session reports that the tail of the file looked spaced out, which indicated UTF-16LE, the encoding Windows PowerShell 5.1 uses for file redirection by default. That doubles the bytes for the same text. The UTF-16 inference came from how the file looked; the encoding was not checked with a byte dump.

Fix proposed

Add three options to the ffmpeg command line:

& $ffmpeg -hide_banner -loglevel warning -nostats -f dshow -i "video=<device name>" ...

• -nostats stops the progress meter.
• -loglevel warning drops the banner and codec detail but keeps warnings and errors, so a log stays useful for diagnosing restarts.
• -hide_banner removes the start-up banner.

As a backstop, at the top of the wrapper's loop, rename the log when it exceeds 10 MB:

if ((Test-Path $log) -and (Get-Item $log).Length -gt 10MB) {
    Move-Item $log "$log.1" -Force
}

The session expected the existing large file to become deletable after the writer restarts, since the file lock is released.

Incidental reading of the progress line

In that line dup=0 drop=98102 against frame=49065 was not a fault: the camera ran at about 30 frames per second and the pipeline decimated to 10 fps with -r 10, so roughly two dropped frames per kept frame is expected.

Unverified

• Whether the three options brought the log growth to near zero was not measured in the sources; the session gave that as its expectation.
• Restarting the wrapper also restarted a media relay that the same scheduled task owned; the session raised the need to stop that process explicitly first, and the outcome is not recorded.