ghostimages/artefacts on recordings

[PhinPhin]

motionEyeOS Version

I am running motionEyeOS version: dev20200907

Board Model

I am using the following board/model: Raspberry Pi 3B

Camera

I am using the following type of camera: V4L2 and Simple MJPEG Camera

Microsoft_Microsoft®_LifeCam_HD-3000
Dlink DCS 930L

Network Connection

My motionEyeOS unit is connected to the network via: Ethernet

Peripherals

I am using the following peripherals that I consider relevant to this issue:

• External USB Hard Disk

Log Files

I consider the following log files relevant to this issue:

boot.log
motioneye.log

I have weird artefacts since 2 days (not sure if it was since the update to the dev-version): both cams got ghost-images of certain image-elements that appear shifted to the left and in some pinkish color. The USB-Camera also has a bright green line at the top of the image. It's not a camera-fault, both cameras work normally. Also the livestream in the webinterface is working correctly but I get those artefacts in all recordings. I use the motion-triggered mode.

[JohanD78]

Have the same issue with the dev20200907 release. Green band on the top ~8% of the recorded video. Livestream shows the image fine. Reverted back to 20190911 build as it is now. Never looked for ghosting so cant say that i saw that tbh.

Problem showed itself on both pi3 and pi4, both with csi cams.

[ccrisan]

@jasaw do you think this issue could be related to OMX zero-copy enabling/disabling on ffmpeg? Merging with latest BuildRoot surely updated a huge deal of packages, including ffmpeg - for which the zero-copy patch wasn't applicable anymore.

[jasaw]

@ccrisan The bright green line is most likely caused by new version of ffmpeg. I haven't figured out why OMX encoding on new ffmpeg causes the green band. We discovered this one year ago but didn't have time to look into it: motioneye-project/motioneye#930 (comment)
The zero-copy patch is not needed anymore because newer version of ffmpeg no longer force enable zero-copy, so allows motion to disable zero-copy. If zero-copy was enabled accidentally, the symptom is the Pi locking up, so this is not caused by zero-copy.

[ccrisan]

@jasaw thanks for your reply. It's good to know the zero-copy issue is gone.

So the workaround for now is to choose a non-OMX-enabled codec, correct?

[jasaw]

@ccrisan That is correct, which is really unfortunate to lose OMX support. Alternatively, we roll back to older ffmpeg for now until the green band problem is fixed.
Somebody should report the issue to motion and ffmpeg. It used to work and obviously someone has broken it recently.

[ccrisan]

@jasaw do you by any chance know which is the last version that works well?

[jasaw]

@ccrisan From memory, I think the green band problem started appearing right after ffmpeg developers removed the forced enable zero-copy, which is early versions of ffmpeg 4.2 (around 20 Aug 2019). The annoying thing is ffmpeg developers didn't bump the micro version number after making such a big interface change, so it's hard to tell exactly which commit within version 4.2 caused the problem.

Long story short, last working ffmpeg version that I tested was version 4.2, before 20 Aug 2019, when I wrote the instructions on how to remove OMX from blacklist: motioneye-project/motioneye#930 (comment)
Also note that if you roll back to that version, you'll need to restore the zero-copy patch.

[PhinPhin]

Sorry for the delayed reply. Indeed, I use H.264/OMX, too. As a workaround, what's the next best codec for low CPU-loads? For now I switched to H.264 (not sure if the V4L setting works stable...?).

[PhinPhin]

Okay, I just noticed 2 cores are now used all the time at 100% and if I want to check a recording in the webinterface the loading-circle appears in the preview and suddenly the Pi crashes and reboots... that can't be good. I think I used OMX for that exact reason. :(

[richardthorrington]

Just to report in, I'm seeing the same thing with my Pi4 and motionEyeOS dev20200907.

Green band across the top and a shift 'ghost' image - picture quality is bad in the recorded footage. I'll try another codec option.

Just for example, this is the quality of the 'live camera'

[ccrisan]

At the suggestion of @popoviciri, upgrading to ffmpeg 4.3.1 may bring some fixes with regards to this problem. The next nightly build will contain ffmpeg 4.3.1.

[nmschulte]

Nightly dev20201012 doesn't seem to resolve these issues for me on Raspberry Pi 3. Choosing a smaller resolution changes the effect from large neon green bar like @richardthorrington shows to an image with color channels translated left/right so they're mis-aligned ("ghosting effect") and three small "channel-colored" rectangles at the top left of the image (thin line, followed by "black" on the rest of the line). Choosing non-OMX video recording removes the issue.

[nmschulte]

@ccrisan I rebuilt after downgrading to ffmpeg 4.2 and still have this issue (RPi3B). The still images and live stream don't suffer, as before.

Also, toggling the "Movie Passthrough" switch doesn't affect the produced video; it even includes theconfigured Text Overlay in the video, so I'm not sure if it's working.

[ccrisan]

@nmschulte as far as I know (from @jasaw), the change happened in early versions of ffmpeg-4.2. We should probably try one of the very first release in 4.2 series or maybe something from 4.1.

[nmschulte]

Building with the attached patch, force-disabling zerocopy for ffmpeg/libavcodec with RPi OMX, resolves the issue for me.

From 2aaa6119218f8c6a509d8b9897fe0d99fa0d665e Mon Sep 17 00:00:00 2001
From: Nathan Schulte <nmschulte@gmail.com>
Date: Sun, 18 Oct 2020 22:38:23 -0500
Subject: [PATCH] ffmpeg: force-disable zerocopy for RPi OMX patch

---
 .../force-disable-rpi-omx-input-zerocopy.patch    | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
 create mode 100644 package/ffmpeg/force-disable-rpi-omx-input-zerocopy.patch

diff --git a/package/ffmpeg/force-disable-rpi-omx-input-zerocopy.patch b/package/ffmpeg/force-disable-rpi-omx-input-zerocopy.patch
new file mode 100644
index 0000000000..c06088caff
--- /dev/null
+++ b/package/ffmpeg/force-disable-rpi-omx-input-zerocopy.patch
@@ -0,0 +1,15 @@
+diff --git a/libavcodec/omx.c b/libavcodec/omx.c
+index 19b4f33836..4641dc79e2 100644
+--- a/libavcodec/omx.c
++++ b/libavcodec/omx.c
+@@ -644,6 +644,10 @@ static av_cold int omx_encode_init(AVCodecContext *avctx)
+     OMX_BUFFERHEADERTYPE *buffer;
+     OMX_ERRORTYPE err;
+ 
++#if CONFIG_OMX_RPI
++    s->input_zerocopy = 0;
++#endif
++
+     s->omx_context = omx_init(avctx, s->libname, s->libprefix);
+     if (!s->omx_context)
+         return AVERROR_ENCODER_NOT_FOUND;
-- 
2.28.0

[PhinPhin]

uhm, how do I fix it? The latest dev-version still has still the same issue, I also tried MKV. Not to mention since a few dev-versions I also got the problem that the written files are corrupted, no idea if that is the same issue? You can see it here: