Source not capturing when rotated

[Doobie Brother]

Zoneminder 1.34.16
ffmpeg 4.3-2
De-branded Dahua camera with two RTSP sources. 25FPS 704x576 stream for motion detection and 2FPS 1920x1080 stream for "archiving".
Have been using this combination successfully for about a year with Zoneminder.
I have decided to physically rotate the camera by 90° and enabled rotation of the stream in the camera. The low-res stream works fine [other than the aspect ratio being wrong, but that's the camera's fault], but the hi-res stream is not.
Before I changed the dimensions of the stream, the hi-res stream worked but is obviously completely distorted and isn't really usable. This is what was logged:

Code: Select all

Jun 21 12:30:40 serverbox zmc_m2[2923037]: WAR [zmc_m2] [Monitor dimensions are 1920x1080 but camera is sending 1080x1920]
Jun 21 12:30:41 serverbox zmc_m2[2923037]: INF [zmc_m2] [Opening video storage stream /var/cache/zoneminder/events/2/2020-06-21/62727/62727-video.mp4 format: mp4]
Jun 21 12:30:41 serverbox zmc_m2[2923037]: INF [zmc_m2] [Event video offset is -0.065 sec (<0 means video starts early)]

I set the dimensions correctly, but then the monitor crashes:

Code: Select all

Jun 21 12:58:05 serverbox zmc_m2[431789]: INF [zmc_m2] [Enabling ffmpeg logs, as LOG_DEBUG+LOG_FFMPEG are enabled in options]
Jun 21 12:58:05 serverbox zmc_m2[431789]: INF [zmc_m2] [Starting Capture version 1.34.16]
Jun 21 12:58:05 serverbox zmc_m2[431789]: INF [zmc_m2] [Priming capture from rtsp://zoneminder:Z0neminder@192.168.1.8:554/cam/realmonitor?channel=1&subtype=2]
Jun 21 12:58:12 serverbox zmc_m2[431789]: INF [zmc_m2] [deprecated pixel format used, make sure you did set range correctly]
Jun 21 12:58:12 serverbox zmc_m2[431789]: ERR [zmc_m2] [Got signal 11 (Segmentation fault), crashing]
Jun 21 12:58:12 serverbox zmc_m2[431789]: ERR [zmc_m2] [Signal address is (nil), from 0x7f4b131989e2]
Jun 21 12:58:12 serverbox zmc_m2[431789]: ERR [zmc_m2] [Backtrace 0: /usr/bin/zmc(_Z14zm_die_handleriP9siginfo_tPv+0x76) [0x55b96fc3ca26]]
Jun 21 12:58:12 serverbox zmc_m2[431789]: ERR [zmc_m2] [Backtrace 1: /lib/x86_64-linux-gnu/libpthread.so.0(+0x14110) [0x7f4b14ee5110]]
Jun 21 12:58:12 serverbox zmc_m2[431789]: ERR [zmc_m2] [Backtrace 2: /lib/x86_64-linux-gnu/libswscale.so.5(+0x749e2) [0x7f4b131989e2]]
Jun 21 12:58:12 serverbox zmc_m2[431789]: INF [zmc_m2] [Backtrace complete, please execute the following command for more information]
Jun 21 12:58:12 serverbox zmc_m2[431789]: INF [zmc_m2] [addr2line -e /usr/bin/zmc 0x55b96fc3ca26 0x7f4b14ee5110 0x7f4b131989e2]

Debug logs:

Code: Select all

06/21/20 12:58:05.011046 zmc_m2[431789].DB1-zm_logger.cpp/247 [LogOpts: level=DB1 effective=DB1, screen=OFF, database=INF, logfile=DB1->/var/log/zm/zm_debug.log.431789, syslog=INF]
06/21/20 12:58:05.011147 zmc_m2[431789].DB1-zm_utils.cpp/285 [Detected a x86\x86-64 processor with AVX]
06/21/20 12:58:05.011419 zmc_m2[431789].DB1-zm_monitor.cpp/2116 [Got 1 for v4l_captures_per_frame]
06/21/20 12:58:05.011450 zmc_m2[431789].INF-zm_ffmpeg.cpp/82 [Enabling ffmpeg logs, as LOG_DEBUG+LOG_FFMPEG are enabled in options]
06/21/20 12:58:05.016944 zmc_m2[431789].DB1-zm_monitor.cpp/423 [monitor purpose=1]
06/21/20 12:58:05.016960 zmc_m2[431789].DB1-zm_monitor.cpp/432 [mem.size(8) SharedData=600 TriggerData=560 VideoStoreData=4128 timestamps=320 images=20x6220800 = 124416000 total=124421672]
06/21/20 12:58:05.017101 zmc_m2[431789].DB1-zm_storage.cpp/84 [Loaded Storage area 1 'Default']
06/21/20 12:58:05.017122 zmc_m2[431789].DB1-zm_monitor.cpp/441 [Storage path: /var/cache/zoneminder/events]
06/21/20 12:58:05.017154 zmc_m2[431789].DB1-zm_monitor.cpp/595 [Unable to map file /dev/shm/zm.mmap.2 (124421672 bytes) to locked memory, trying unlocked]
06/21/20 12:58:05.017166 zmc_m2[431789].DB1-zm_monitor.cpp/598 [Mapped file /dev/shm/zm.mmap.2 (124421672 bytes) to unlocked memory]
06/21/20 12:58:05.053982 zmc_m2[431789].DB1-zm_monitor.cpp/507 [Monitor backcam-hi has function 4,
label format = '%N - %Y-%m-%d %H:%M:%S %z', label X = 0, label Y = 0, label size = 2,
image buffer count = 20, warmup count = 0, pre-event count = 0, post-event count = 5, alarm frame count = 1,
fps report interval = 10000, ref blend percentage = 12, alarm ref blend percentage = 12, track motion = 0]
06/21/20 12:58:05.054399 zmc_m2[431789].DB1-zm_zone.cpp/884 [Got 1 zones for monitor backcam-hi]
06/21/20 12:58:05.063705 zmc_m2[431789].DB1-zm_monitor.cpp/2389 [Loaded monitor 2(backcam-hi), 1 zones]
06/21/20 12:58:05.063741 zmc_m2[431789].INF-zmc.cpp/223 [Starting Capture version 1.34.16]
06/21/20 12:58:05.069391 zmc_m2[431789].INF-zm_ffmpeg_camera.cpp/202 [Priming capture from rtsp://zoneminder:Z0neminder@192.168.1.8:554/cam/realmonitor?channel=1&subtype=2]
06/21/20 12:58:05.074662 zmc_m2[431789].DB1-zm_ffmpeg_camera.cpp/365 [Calling avformat_open_input for rtsp://zoneminder:Z0neminder@192.168.1.8:554/cam/realmonitor?channel=1&subtype=2]
06/21/20 12:58:12.407041 zmc_m2[431789].DB1-zm_ffmpeg_camera.cpp/458 [Failed to find decoder (h264_mmal)]
06/21/20 12:58:12.407088 zmc_m2[431789].DB1-zm_ffmpeg.cpp/335 [Dumping stream index i(0) index(0)]
06/21/20 12:58:12.407096 zmc_m2[431789].DB1-zm_ffmpeg.cpp/345 [    Stream #0:0]
06/21/20 12:58:12.407103 zmc_m2[431789].DB1-zm_ffmpeg.cpp/353 [frames:12, frame_size:0 stream timebase: 1/90000]
06/21/20 12:58:12.407109 zmc_m2[431789].DB1-zm_ffmpeg.cpp/359 [codec: h264]
06/21/20 12:58:12.407115 zmc_m2[431789].DB1-zm_ffmpeg.cpp/286 [2 fps]
06/21/20 12:58:12.407121 zmc_m2[431789].DB1-zm_ffmpeg.cpp/288 [90k stream tb numerator]
06/21/20 12:58:12.407185 zmc_m2[431789].DB1-zm_ffmpeg.cpp/310 [Dumping codec_context codec_type(0) codec_id(27 h264) width(1080) height(1920)  timebase(1/4) format(yuvj420p) gop_size 12 max_b_frames 0 me_cmp 0 me_range 0 qmin 2 qmax 31]
06/21/20 12:58:12.407200 zmc_m2[431789].DB1-zm_ffmpeg_camera.cpp/561 [HWACCEL not in use]
06/21/20 12:58:12.445762 zmc_m2[431789].DB1-zm_ffmpeg_camera.cpp/989 [raw frame from decoder: format 12 yuvj420p 1080x1920 linesize:1152x576 pts: 268200]
06/21/20 12:58:12.445848 zmc_m2[431789].INF-zm_ffmpeg.cpp/70 [deprecated pixel format used, make sure you did set range correctly]
06/21/20 12:58:12.457606 zmc_m2[431789].DB1-zm_ffmpeg_camera.cpp/1117 [Setup conversion context for 1080x1920 yuvj420p to 1080x1920 rgb24]
06/21/20 12:58:12.457643 zmc_m2[431789].ERR-zm_signal.cpp/52 [Got signal 11 (Segmentation fault), crashing]
06/21/20 12:58:12.463388 zmc_m2[431789].DB1-zm_signal.cpp/60 [Signal information: number 11 code 128 errno 0 pid 0 uid 0 status 0]
06/21/20 12:58:12.463411 zmc_m2[431789].ERR-zm_signal.cpp/83 [Signal address is (nil), from 0x7f4b131989e2]
06/21/20 12:58:12.468977 zmc_m2[431789].ERR-zm_signal.cpp/104 [Backtrace 0: /usr/bin/zmc(_Z14zm_die_handleriP9siginfo_tPv+0x76) [0x55b96fc3ca26]]
06/21/20 12:58:12.474801 zmc_m2[431789].ERR-zm_signal.cpp/104 [Backtrace 1: /lib/x86_64-linux-gnu/libpthread.so.0(+0x14110) [0x7f4b14ee5110]]
06/21/20 12:58:12.480628 zmc_m2[431789].ERR-zm_signal.cpp/104 [Backtrace 2: /lib/x86_64-linux-gnu/libswscale.so.5(+0x749e2) [0x7f4b131989e2]]
06/21/20 12:58:12.486660 zmc_m2[431789].INF-zm_signal.cpp/111 [Backtrace complete, please execute the following command for more information]
06/21/20 12:58:12.492301 zmc_m2[431789].INF-zm_signal.cpp/112 [addr2line -e /usr/bin/zmc 0x55b96fc3ca26 0x7f4b14ee5110 0x7f4b131989e2]

I am wondering if "deprecated pixel format used, make sure you did set range correctly" is the key here as that message does not appear if I don't tell Zoneminder the correct dimensions.

[Doobie Brother]

Seeing as the wrong dimensions of 1920x1080 doesn't crash the source, on a hunch I have tried changing the dimensions in Zoneminder to 1088x1920 and 1072x1920, and both work without crashing, and are close enough not to look silly.

[bbunge]

Seeing as the wrong dimensions of 1920x1080 doesn't crash the source, on a hunch I have tried changing the dimensions in Zoneminder to 1088x1920 and 1072x1920, and both work without crashing, and are close enough not to look silly.

One way to get a good resolution setting is to use VLC (Tools, Media Information, Codec) to check camera Display Resolution. Then, you can usually halve (and quarter) the resolution settings in Zoneminder to get a smaller image.

Often, users assume the advertised resolution of a camera will work in Zoneminder. And when it doesn't they blame Zoneminder.

And remember Zoneminder is a security system not a HD video system. Video at 640X480 @ 5 FPS has sent perps to jail.

[iconnor]

This is pretty weird. Unfortunately I don't have any cameras that will actually do rotation in-camera. Until I can figure out a stream at 1080x1920 I'm going to be hard pressed to reproduce and fix.

Github issue created here: https://github.com/ZoneMinder/zoneminder/issues/2968

[mikb]

It may be that 1920 divides exactly by 16, yet 1080 does NOT divide by 16.

I've come across general video-handling-with-FFMPEG problems when using X-resolutions that are not exact multiples of 16, so have become sensitive to that one

[Doobie Brother]

Why would divisibility by 16 matter in one dimension but not another?

[iconnor]

I suspect about the 16 as well. You can use various SIMD instructions and loop unrolling and other techniques for significant performance gains if you can assume that the data that you are working on is 32bit aligned. So we have checks for that.

Problem is NONE of my cameras do rotation. They are all only flip and mirror. Grr. Probably my best bet at this point is to use a pi as a camera.

[mikb]

Why would divisibility by 16 matter in one dimension but not another?

As per iconnor's post -- I just discovered that when batch transcoding videos at their "supplied size" into xvid/mp4 formats, I would get a hard "segmentation fault" refusal from FFMPEG for some of them. The only thing in common was non-standard resolutions.

One of the tips I discovered was making sure the horizontal resolution was a multiple of 8, preferably 16. So I always check for /16 roundness. If not, I force the video to be the nearest multiple of 16 (across) before encoding.

No mention of the vertical, and I never tripped up on that, although sometimes you get a bit of weirdness in the bottom few lines of the video as if some bad data might be leaking in, green bits etc. but nothing overly bad.

[Doobie Brother]

There is definitely something "magical" about 1080. I have just tried 1087x1920, 1075x1920, 1096x1920 and 1080x1920 and the only one that had a problem is 1080x1920.

[mikb]

Well that's even worse, because that collection of horizontal resolutions are ALL indigestible by 16

As in -- I would hope they all make something feel unwell!

[mastertheknife]

Hi, i wrote the 12 byte (24bit color) 16 byte (32bit color) limitation. On ARM i believe the 32bit color is 64 bytes.
Technically its possible to remove it, by adding special handling code for the remaining bytes.

I want to correct what has been said in this thread. The limitation is for the total amount of pixels, rather than vertical or horizontal.
For example 1920*1080 = 2073600
2073600 is dividable by 12, 16 and also 64.
This isn't the source of the problem, at least not a limitation within ZM. Perhaps you're referring to ffmpeg limitations?

[mikb]

Hi, i wrote the 12 byte (24bit color) 16 byte (32bit color) limitation. On ARM i believe the 32bit color is 64 bytes.
Technically its possible to remove it, by adding special handling code for the remaining bytes.

I want to correct what has been said in this thread. The limitation is for the total amount of pixels, rather than vertical or horizontal.
For example 1920*1080 = 2073600
2073600 is dividable by 12, 16 and also 64.
This isn't the source of the problem, at least not a limitation within ZM. Perhaps you're referring to ffmpeg limitations?

I was indeed referring to FFMPEG, and did so explicitly in both my postings.

Agreed, if the limitation you speak of (total pixels div by 12/16) mattered here, then 1920x1080 and 1080x1920 would both work the same, as the total number of pixels is the same.

They don't (as per the original post).

[iconnor]

FYI fix is in master, but it's a big change so I'm letting it sit there for a bit before releasing 1.34.17.

The issue is that sws_scale in latest ffmpeg can't handle the WIDTH not being a multiple of 32. Technically it is the line_size, which is the # of bytes to contain a line, which can be > width*bytes_per_pixel.

We didn't take this into account in any of our imaging code. Now we do.

[randoom]

Seems, fix is not working on v1.36.33
1088x1920 works
Could you please check this?