Incorrect Log Entry for External FFmpeg pipe (movie_extpipe_use on)

[rdorsch]

Did you read the guide?

Yes

What is the base version number of Motion being used?

4.7.x

What was the install method?

Installed via package tool

What is base architecture?

x86/x64

What is the distro being used?

Debian

Disto version number

13.6

Camera/Sound type(s) being used?

Network camera with RTSP

Describe the issue/problem and steps to reproduce

This is a borderline issue, could also go as enhancement.

Issue Summary

When using Motion with movie_extpipe to enforce custom encoding settings (such as generating H.264 MP4 files with -profile:v high and -movflags +faststart for mobile browser compatibility, e.g., Firefox on Android), Motion's internal logger (event_newfile) outputs an incomplete file path that lacks the file extension.

While FFmpeg correctly creates the file on disk (e.g., path/filename.mp4), Motion's system logs report writing to path/filename without the .mp4 extension.

Background & Problem Description

Root Cause for extpipe: Standard built-in Motion movie generation outputs containers that may fail to stream smoothly or play natively on mobile browsers (such as Firefox on Android) due to missing yuv420p pixel format constraints or missing MOOV atom faststart placement (-movflags +faststart).

The Workaround: To resolve playback issues, movie_extpipe is used to pipe raw video directly into an external FFmpeg process:

movie_extpipe_use on
movie_extpipe ffmpeg -y -f rawvideo -pix_fmt yuv420p -video_size %wx%h -framerate %{fps} -i pipe:0 -vcodec libx264 -profile:v high -pix_fmt yuv420p -movflags +faststart -f mp4 %f.mp4

The Logging Bug: Motion's %f variable represents the base path without an extension. When FFmpeg runs, it evaluates %f.mp4 and writes the correct file to disk. However, Motion's internal logging routine in event.c logs %f directly.

Steps to Reproduce

Configure motion.conf to use movie_extpipe appending .mp4 to %f:

movie_filename CAM0_%t-%Y%m%d-%H%M%S-%v
movie_extpipe_use on
movie_extpipe ffmpeg ... -f mp4 %f.mp4

Trigger a motion detection event.

Observe the system logs (journalctl / Motion logs).

Expected Behavior

The log entry should reflect the actual destination file created on disk:

[1:ml1:Cam1] [NTC] [EVT] event_newfile: Writing movie to file: /path/to/CAM1_101-20260904-111339-01.mp4

Actual Behavior

The execution pipe log evaluates correctly, but the subsequent Motion event_newfile log omits the .mp4 extension:

[1:ml1:Cam1] [NTC] [EVT] event_create_extpipe: pipe: ffmpeg ... -f mp4 /path/to/CAM1_101-20260904-111339-01.mp4
[1:ml1:Cam1] [NTC] [EVT] event_newfile: Writing movie to file: /path/to/CAM1_101-20260904-111339-01

Suggested Fix

Introduce a dedicated configuration option, such as movie_extpipe_extension or movie_filename_extension (e.g., movie_filename_extension mp4), to explicitly declare the file extension when using external piping (at least for the logging part).

Relevant Motion log output (at log_level 8)

[1:ml1:Cam1] [NTC] [EVT] event_create_extpipe: pipe: ffmpeg ... -f mp4 /path/to/CAM1_101-20260904-111339-01.mp4
[1:ml1:Cam1] [NTC] [EVT] event_newfile: Writing movie to file: /path/to/CAM1_101-20260904-111339-01

[tosiara]

IMO, the behaviour is correct. Motion has no knowledge about the pipe command logic, what container it uses and what file it writes. The pipe command can write into a completely unrelated file. That's why the file name intentionally is missing the extension, and it is up to ext pipe command to append whatever it needs

[rdorsch]

I agree with the part you describe, my report refers to the log entry, which is incorrect:

[1:ml1:Cam1] [NTC] [EVT] event_newfile: Writing movie to file: /path/to/CAM1_101-20260904-111339-01

This file does not exist, since the extension is missing.

An alternative solution would probably be to allow a custom log string, if movie_extpipe is used.

[tosiara]

But it is what it is, literally:

File name(without extension)

motion/data/motion-dist.conf.in

Line 128 in 04e4a05

# File name(without extension) for movies relative to target directory

[rdorsch]

The behavior corresponds to the documentation, but if I read the log file, the information in there implies that the file does not have an extension, whereas the same message is printed with extension, e.g.

[2:ml2:Cam2] [NTC] [EVT] [Sep 02 13:07:14] event_newfile: Writing movie to file: /mnt/disk/scratch2/motion/cam2/CAM2_102-20260902-130706-129.mkv

if movie_extpipe is not used.