MJPEG netcam is always shown in 640x480

[kingkingyyk]

motioneye/extra/linux_init always install latest motion, but motioneye doesn't necessarily support it.

For example, in 4.4.0 introduced new configuration options that causes this issue where motion doesn't support writing the new configuration yet.

[MichaIng]

motionEye does support motion v4.4, which is why this change was done: #2462

Did you run into any specific issue with latest motion and motionEye? Probably we missed migration for a specific config key.

[kingkingyyk]

I have 1920x1080 mjpeg stream added via Network Camera, but the preview / video from motion becomes 640x480. This issue is not reproducible with 4.3.2

[MichaIng]

You mean a simple MJPEG stream? That is not passed through motion at all, is it? Or do you mean an RTSP or RTMP stream? In this case you should be able to use the resolution option in camera settings.

Do you use custom motion arguments? We just internally translate those which are used by the options in UI, while for custom parameters you need to assure those do match the motion version.

Lastly, does motion, if used at all for this stream, report any warning about unknown config keys?

[kingkingyyk]

• HTTP MJPEG stream added as Network Camera so motion is used
• Nope.
• Nope.

[MichaIng]

Does the URL to the network camera start with rtsp:// or rtmp://? Because only in this case the width/height from the resolution input is used, otherwise it is ignored (not sure whether still displayed?). This is and was the same, regardless which motion version is used. See here:

• https://github.com/motioneye-project/motioneye/blob/24f63c3/motioneye/config.py#L695-L697
• https://github.com/motioneye-project/motioneye/blob/24f63c3/motioneye/config.py#L975-L987
• https://github.com/motioneye-project/motioneye/blob/24f63c3/motioneye/config.py#L1437-L1451

If I see it right, the resolution is not set anywhere for netcams with other URL schemes. Can you show the related camera config?

cat /etc/motioneye/camera-1.conf

Adjust the number to match the netcam. And if you find time, doing the same with motion v4.3.2 would be great.

[kingkingyyk]

It starts with HTTP.

This is how it looks like in v4.3.2

threshold_maximum 0
stream_quality 40
threshold 30720
noise_level 31
smart_mask_speed 0
pre_capture 10
movie_codec mp4:h264_omx
noise_tune on
stream_maxrate 25
netcam_url http://172.17.0.1:8764/
stream_localhost on
text_changes on
movie_filename %Y-%m-%d/%H-%M-%S
movie_max_time 30
lightswitch_percent 50
movie_passthrough off
auto_brightness off
stream_port 8081
rotate 0
stream_auth_method 0
threshold_tune off
framerate 20
emulate_motion off
movie_output off
picture_quality 50
snapshot_filename %Y-%m-%d/%H-%M-%S
despeckle_filter
snapshot_interval 0
minimum_motion_frames 5
stream_motion off
target_dir /var/lib/motioneye/Camera1
movie_output_motion off
post_capture 10
on_picture_save /usr/local/lib/python3.9/dist-packages/motioneye/scripts/relayevent.sh "/etc/motioneye/motioneye.conf" picture_save %t %f
on_movie_end /usr/local/lib/python3.9/dist-packages/motioneye/scripts/relayevent.sh "/etc/motioneye/motioneye.conf" movie_end %t %f
text_left Camera1
picture_output_motion off
picture_filename %Y-%m-%d/%H-%M-%S
text_scale 4
locate_motion_style redbox
locate_motion_mode on
netcam_keepalive off
movie_quality 50
picture_output on
on_event_end /usr/local/lib/python3.9/dist-packages/motioneye/scripts/relayevent.sh "/etc/motioneye/motioneye.conf" stop %t
text_right %Y-%m-%d\n%T
on_event_start /usr/local/lib/python3.9/dist-packages/motioneye/scripts/relayevent.sh "/etc/motioneye/motioneye.conf" start %t
camera_name Camera1
event_gap 10
netcam_tolerant_check on
mask_file

[MichaIng]

So as expected no resolution/width/height is defined at all. With motion 4.5.1, when accessing the stream directly at port 8081 has 640x480 resolution applied as well, or is it full HD there?

[kingkingyyk]

It is 640x480, downsized from full HD, so the image looks compressed horizontally as the aspect ratio becomes tighter.

[MichaIng]

Then it seems to be a bug in motion itself, since the config does not enforce any resolution. In this case I'd expect it to show the stream unmodified. Reading the docs, however, it seems the default is (now) 640x480 and enforced for the output stream, even if the original stream has a different resolution and is not actually rescaled: https://motion-project.github.io/motion_config.html#width

This seems dumb to me. The default, if nothing enforced, should be the input stream. Can you test with motion v4.4 to narrow down where the change happened? https://github.com/Motion-Project/motion/releases/tag/release-4.4.0

If this is somehow a wanted change, we'd need to expose the width/height setting for all camera types, but in case of a netcam stream obtain the original resolution and apply this when the camera is created (as default). But I'm not sure how to obtain the original resolution.

[kingkingyyk]

I've actually tested on 4.4.0 as well, it does have the same issue. It should be easy to obtain the resolution by just reading a single frame the moment the stream url is added, but if someone decided to change the source without readding, then the resolution would remain unchanged.

[MichaIng]

I've actually tested on 4.4.0 as well, it does have the same issue.

Okay, good to know. There is an issue/discussion about this, older than motion 4.4: Motion-Project/motion#1489
It actually sounds like auto-detection is already done if no "global values" are defined. Indeed the default /etc/motion/motion.conf does (and also did with motion 4.3.2) contain 640x480 as default values. motionEye uses its own config at /etc/motioneye/motion.conf. Currently not sure whether this sets width/height as well. If it does, a test would be to remove those and check whether the stream then has original size. The question remains why this changed with motion 4.4 since width/height values are obtained and applied by motionEye independent of the motion version.

by just reading a single frame the moment the stream url is added

Indeed, I mean that my Python and PIL knowledge is insufficient to know how to implement this. Would require some spare time to look into the code. I think the code around the masks already does this, so could be reused as basis to obtain and measure dimensions of a single frame when adding a new netcam.

I will test a bit as well so see what we can do our end and collect all info required to do a proper report at the motion repo.

[kingkingyyk]

motionEye writes a config file to /etc/motioneye/camera-1.conf and gets motion to read from the file, so I think the default /etc/motion/motion.conf should not be affecting.

Let's see if I can manage to do a pull request on this matter.

[MichaIng]

It creates an /etc/motioneye/motion.conf (within "motioneye" config dir, no "motion" config dir) as well, isn't it?