BUG: height (1080) is not modulo 16 3.2.12: with 1920 x 1080

Camera sending 1920 x 1080 fails with: netcam image height (1080) is not modulo 16

A) I tried changing netcam.c where the check occurs to be '% 8' instead of 16 - but doing this leads to a crash. Not familiar enough with code to know how to 'patch' this issue.

B) I also tried running trunk but that just gets streams of lines like : netcam_read_html_jpeg: Potential split boundary - XXX chars flushed, 1 re-positioned

The modulo 16 has been fixed here but presumably more than the 1 spot I found.

But it never stabilizes and connects - just loops with above error (XXX varies).

C) Weirdly I have 2 cameras - problem started when I upgraded the firmware on one to test it - prior to this I did not hit this modulo 16 problem. The one with older firmware works at 1920 x 1080 - both are sending MJPEG.

D) Also sometimes 3.2.12 crashes - this is what I see when that happens: motion[7290]: [1] netcam image height (1080) is not modulo 16 motion[7290]: [1] Could not fetch initial image from camera motion[7290]: [1] Motion continues using width and height from config file(s) motion[7290]: [1] Resizing pre_capture buffer to 1 items motion[7290]: [1] Retrying until successful connection with camera motion[7290]: [1] netcam image height (1080) is not modulo 16 motion.service: main process exited, code=killed, status=11/SEGV

E) I tried rtsp instead of http (still using MJPEG) but this just gives error: Invalid netcam_url same url works fine in vlc rtsp://<ip>:554/0

F) Is H264 planned any time soon?

Thanks for help.

========= Update

I took the "3.4" patches (patchworkfornew release bundle) on top of trunk.

I have it set to save video and center jpeg.

Now it gets further - it crashes in libjpeg.so

If I turn of saving any jpeg - then it gets further but crashes

motion.c line 2094 calling event()

=

suggestions how to fix this?

Environment

Motion version:	3.2.12
ffmpeg version:	ffmpeg 1:2.4.4-1
Shared libraries:	ffmpeg
Server OS:	Arch Linux kernel 3.18.rc7

-- GeneC - 04 Dec 2014

Follow up

One addition - if I start 3.4 it seems to start up fine and connect to camera - however as soon as a client browser connects to any of the 808x web servers - it SEGVs immediately. I will build a debuggable this weekend and see what running in a debugger shows.

Will keep you posted.

When I try this the debugger gets a load of sigpipes - which I igore ... i have 6 cameras - 8081 - 8085 are visible in client - 8086 is not - i do see logs howing cam-6 detected motion and saved a video file - so far debugger has not crashed.

Running outside debugger crashes with SEGV. Inside no web stream for camera 6. Weird.

Feels like a some kind of race going on that is masked by running in debugger ...

I can tell gdb to ignore sigpipe - so its still running in debugger - 1 out of 6 camera is a problem - the problem camera is not always the same one. The problem one has has motion log showing:

netcam_init_jpeg: no new pic, no signal rcvd

The other 5 work fine running in debugger - out of the debiugger i quickly get a SEGV when client connects to the 808x web servers.

I ran in the debugger for several hours - one camera all the while not visible on it's 808x port. Then I rebooted the camera which was not showing. Motion connected according to the log - but right after that when the browser client connected to its 808x web server it crashed in the debugger with this backtrace:

(gdb) bt
#0 0x00007ffff77089df in ?? () from /usr/lib/libjpeg.so.8
#1 0x00007fffe4000fa0 in ?? ()
#2 0x0000000000000008 in ?? ()
#3 0x00007ffff77015d0 in ?? () from /usr/lib/libjpeg.so.8
#4 0x00007ffff7701530 in ?? () from /usr/lib/libjpeg.so.8
#5 0x00007ffff7701590 in ?? () from /usr/lib/libjpeg.so.8
#6 0x0000000000000000 in ?? ()

Not sure how helpful this is. Bu something is definitely not right with the code - but the 3.4 code is about the best there is from what I am seeing - but it still has some severe problem.

Fix record