Send Motion-user mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/motion-user
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Motion-user digest..."
Today's Topics:
1. HD Netcams (Harlan Daneker)
2. Re: HD Netcams (John Baker)
3. Re: HD Netcams (Mike Wilson)
4. Re: HD Netcams (Scott W. Larson)
5. patch to netcam.c to normalize log levels and fix one
reporting error (Noel Cragg)
6. mpeg4 is not supported (John Baker)
7. Re: mpeg4 is not supported (John Baker)
----------------------------------------------------------------------
Message: 1
Date: Tue, 10 May 2016 12:40:15 -0400
From: Harlan Daneker <[email protected]>
Subject: [Motion-user] HD Netcams
To: Motion discussion list <[email protected]>
Message-ID:
<cac1wkisyrvzovyh5qno6gczt+9xara2vpd2dpoz6ps7uhe_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Has anybody used high definition network cameras with motion? Do they work?
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 2
Date: Tue, 10 May 2016 17:50:14 +0100
From: John Baker <[email protected]>
Subject: Re: [Motion-user] HD Netcams
To: [email protected]
Message-ID:
<1462899014.1199356.603742009.4cb50...@webmail.messagingengine.com>
Content-Type: text/plain
Yes, but it depends which camera. I was not impressed with the Foscam
C1. I trusted a brand and I should have bought a cheap Chinese camera -
the Foscam only supports one client via RTSP only!
On Tue, May 10, 2016, at 05:40 PM, Harlan Daneker wrote:
> Has anybody used high definition network cameras with motion? Do they
> work?
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> Motion-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/motion-user
> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
------------------------------
Message: 3
Date: Tue, 10 May 2016 16:51:49 +0000
From: Mike Wilson <[email protected]>
Subject: Re: [Motion-user] HD Netcams
To: Motion discussion list <[email protected]>
Message-ID:
<caaveucouuaj2rwjog+u-ujpvbh0rtfc5smj8at4njxr8bcy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I've been using random RTSP IP cameras for a while now. You need a beefy PC
to process that large of an image, but I've been doing 1920x1080 and only
really notice issues of variable framerate when saving videos. I keep
thinking I'll make a pull request with reduced frame size motion detection,
but I haven't done it.
On Tue, May 10, 2016 at 12:41 PM Harlan Daneker <[email protected]> wrote:
> Has anybody used high definition network cameras with motion? Do they work?
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> Motion-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/motion-user
> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 4
Date: Tue, 10 May 2016 09:55:13 -0700
From: "Scott W. Larson" <[email protected]>
Subject: Re: [Motion-user] HD Netcams
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 05/10/2016 09:40 AM, Harlan Daneker wrote:
> Has anybody used high definition network cameras with motion? Do they
> work?
>
I have a 720p Foscam FI9821W working with motion. Well, it returns 720p
video but the camera clearly upscales a lower resolution image.
------------------------------
Message: 5
Date: Sun, 15 May 2016 12:00:45 -0700
From: Noel Cragg <[email protected]>
Subject: [Motion-user] patch to netcam.c to normalize log levels and
fix one reporting error
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I'm still using some older IP cameras in the mode where one frame is
retrieved at a time. With the default logging level set to NTC, this
results in a huge amount of logspew.
After reading the other source files, it seemed to me that these
messages really belonged in a different category than NTC. In other
files, NTC messages appear mostly to report actual changes of state
(e.g. conf.c reports loading and saving config files; event.c reports
writing files to disk; motion.c reports overall thread
creation/deletion as well as opening/closing of video devices). One
level down, the few INF messages appear to report on the execution
path taken through the code level (e.g. netcam_jpeg.c reports on
processing of individual frames).
Based on treating NTC=change and INF=trace, there are arguably more
messages which could be moved to INF. However, since I've not been
involved on a code level previously and I'm not actively using the
other features whose messages might be moved, I only wanted to modify
things that addressed my active use case.
There's also a trivial bugfix at the end of netcam_read_html_jpeg().
The existing behavior for non-keepalive cameras emitted the following
log lines:
[1] [NTC] [NET] [May 15 11:55:10] netcam_read_html_jpeg: disconnecting netcam
since keep-alive not set.
[1] [NTC] [NET] [May 15 11:55:10] netcam_read_html_jpeg: leaving netcam
connected.
That conditional was simply missing an 'else' clause.
-------------- next part --------------
Index: netcam.c
===================================================================
--- netcam.c (revision 564)
+++ netcam.c (working copy)
@@ -644,10 +644,10 @@
switch (ret) {
case 1: /* Not streaming */
if (netcam->connect_keepalive)
- MOTION_LOG(NTC, TYPE_NETCAM, NO_ERRNO, "%s: Non-streaming
camera "
+ MOTION_LOG(INF, TYPE_NETCAM, NO_ERRNO, "%s: Non-streaming
camera "
"(keep-alive set)");
else
- MOTION_LOG(NTC, TYPE_NETCAM, NO_ERRNO, "%s: Non-streaming
camera "
+ MOTION_LOG(INF, TYPE_NETCAM, NO_ERRNO, "%s: Non-streaming
camera "
"(keep-alive not set)");
netcam->caps.streaming = NCS_UNSUPPORTED;
@@ -690,7 +690,7 @@
}
} else if ((ret = (int) netcam_check_content_length(header)) >= 0) {
- MOTION_LOG(NTC, TYPE_NETCAM, NO_ERRNO, "%s: Content-length
present");
+ MOTION_LOG(INF, TYPE_NETCAM, NO_ERRNO, "%s: Content-length
present");
if (ret > 0) {
netcam->caps.content_length = 1; /* Set flag */
@@ -715,7 +715,7 @@
* This flag is acted upon below.
* Changed criterion and moved up from below to catch headers that
cause returns.
*/
- MOTION_LOG(NTC, TYPE_NETCAM, NO_ERRNO, "%s: Found Conn: close
header ('%s')",
+ MOTION_LOG(INF, TYPE_NETCAM, NO_ERRNO, "%s: Found Conn: close
header ('%s')",
header);
}
free(header);
@@ -1358,12 +1358,13 @@
if (netcam->caps.streaming == NCS_UNSUPPORTED) {
if (!netcam->connect_keepalive) {
- MOTION_LOG(NTC, TYPE_NETCAM, NO_ERRNO, "%s: disconnecting "
+ MOTION_LOG(INF, TYPE_NETCAM, NO_ERRNO, "%s: disconnecting "
"netcam since keep-alive not set.");
netcam_disconnect(netcam);
- }
- MOTION_LOG(NTC, TYPE_NETCAM, NO_ERRNO, "%s: leaving netcam
connected.");
+ } else {
+ MOTION_LOG(INF, TYPE_NETCAM, NO_ERRNO, "%s: leaving netcam
connected.");
+ }
}
return 0;
@@ -2310,7 +2311,7 @@
}
}
- MOTION_LOG(NTC, TYPE_NETCAM, NO_ERRNO, "%s: connected,"
+ MOTION_LOG(INF, TYPE_NETCAM, NO_ERRNO, "%s: connected,"
" going on to read image.");
netcam->get_image = netcam_read_html_jpeg;
@@ -2350,7 +2351,7 @@
* We are positionned right just at the start of the first MJPG
* header, so don't move anymore, initialization complete.
*/
- MOTION_LOG(NTC, TYPE_NETCAM, NO_ERRNO, "%s: connected,"
+ MOTION_LOG(INF, TYPE_NETCAM, NO_ERRNO, "%s: connected,"
" going on to read and decode MJPG chunks.");
netcam->get_image = netcam_read_mjpg_jpeg;
------------------------------
Message: 6
Date: Thu, 26 May 2016 19:13:52 +0100
From: John Baker <[email protected]>
Subject: [Motion-user] mpeg4 is not supported
To: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain
I recompiled motion from mr dave's fork (which I'd previously compiled
successfully) and suddenly it's saying this:
[1] [ERR] [ENC] get_oformat: ffmpeg_video_codec option value mpeg4' is
not supported.
Does anyone know why?
------------------------------
Message: 7
Date: Fri, 27 May 2016 11:50:37 +0100
From: John Baker <[email protected]>
Subject: Re: [Motion-user] mpeg4 is not supported
To: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain
Actually, this is some kind of stack corruption occurring when I changed
the compile time flags (-O2 to -O0). I fixed it by a change in event.c:
//char codec_mpeg[5] = "mpeg4";
const char *codec_mpeg = "mpeg4";
But this generates other compiler warnings. I'm no expert in C, but
perhaps Mr Dave could put this patch properly in place and fix the
compiler warnings with respect to the constant.
I'm trying to figure out why I see crashing from the rtsp code, hence
the -O0 change to get line numbers from a core dump. I shall report
back if I make any further progress.
On Thu, May 26, 2016, at 07:13 PM, John Baker wrote:
> I recompiled motion from mr dave's fork (which I'd previously compiled
> successfully) and suddenly it's saying this:
>
> [1] [ERR] [ENC] get_oformat: ffmpeg_video_codec option value mpeg4' is
> not supported.
>
> Does anyone know why?
------------------------------
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
------------------------------
_______________________________________________
Motion-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/motion-user
End of Motion-user Digest, Vol 120, Issue 2
*******************************************
