Send Motion-user mailing list submissions to
motion-user@lists.sourceforge.net
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
motion-user-requ...@lists.sourceforge.net
You can reach the person managing the list at
motion-user-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Motion-user digest..."
Today's Topics:
1. Suggestion for IP CAM (Markus Tobatz)
2. Re: Suggestion for IP CAM (S Andreason)
3. Re: Suggestion for IP CAM (Roger Heflin)
4. Re: Reolink 410w video problem (Steve)
----------------------------------------------------------------------
Message: 1
Date: Sat, 10 Jul 2021 16:30:29 +0200
From: Markus Tobatz <markus.tob...@gmail.com>
To: motion-user@lists.sourceforge.net
Subject: [Motion-user] Suggestion for IP CAM
Message-ID:
<CAB9JKDCSWJrbh1rXnJeGtkvNWdxpM=zyjq-wl4ywdfnf4gm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I'm using Unify products for some years now, but I'm not satisfied with
function of Unify Video software and the image quality of the cams
decreases over the years. A big pro for Unify its their low CPU usage.
Now I thought about switching to Motion and MotionEye and I wondered if
there is any list for suggested cameras? Best thing would be any UHD/4k IP
network camera. As I'm using motion detection it's very important to me,
that the 6 network cameras I want to attach result in a really low CPU
usage.
(For a test of Motion I've added the Unify cam via RTSP stream in FullHD
and that resulted in 90% CPU usage just for that one camera)
Can anyone help?
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 2
Date: Sat, 10 Jul 2021 08:08:51 -0700
From: S Andreason <sandrea...@gmail.com>
To: Motion-user <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Suggestion for IP CAM
Message-ID: <3e07a47c-5cc5-b063-5114-e3643c310...@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Markus,
Check the camera's video encoding setting, H264 uses less CPU to decode
than H265/HEVC.
and of course, the higher the resolution, the slower things will go.
Markus Tobatz wrote:
> ?RTSP stream in FullHD and that resulted in 90% CPU usage just for
> that one camera)
------------------------------
Message: 3
Date: Sat, 10 Jul 2021 18:56:42 -0500
From: Roger Heflin <roger.hef...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Suggestion for IP CAM
Message-ID:
<CAAMCDefunWxAfxd-3YBARxkGGseV8j5k0CGs0jz99=tkzgb...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Something else to note, the higher the resolution almost always means
worse low light performance (given the same sensor technology), so if
you need low light you may want to reconsider 4k cams, or you may want
to use a mixture.
1/2 the pixels with the same sensor size gets 2x the light and works
better at night. And almost all of the security cam type devices have
roughly the same sensor size.
On Sat, Jul 10, 2021 at 10:10 AM S Andreason <sandrea...@gmail.com> wrote:
>
> Hi Markus,
> Check the camera's video encoding setting, H264 uses less CPU to decode
> than H265/HEVC.
> and of course, the higher the resolution, the slower things will go.
>
>
> Markus Tobatz wrote:
> > RTSP stream in FullHD and that resulted in 90% CPU usage just for
> > that one camera)
>
>
>
> _______________________________________________
> Motion-user mailing list
> Motion-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/motion-user
> https://motion-project.github.io/
>
> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
------------------------------
Message: 4
Date: Sat, 10 Jul 2021 18:35:28 -0600
From: Steve <sch...@msn.com>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Reolink 410w video problem
Message-ID:
<by3pr08mb71235971828a56be91929a9ec5...@by3pr08mb7123.namprd08.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
A week later and not a single video issue. Thanks again, James
On 7/3/21 8:45 PM, Steve wrote:
> James, you are a prince. Works a charm. Time will tell if my problem is
> resolved but I'm feeling hopeful.
>
> On 7/3/21 7:53 PM, James Smith wrote:
>> I used the following URL format which I found in this document
>> Reolink-CGI-command-v1.61.pdf
>> <https://reolink.com/wp-content/uploads/2017/01/Reolink-CGI-command-v1.61.pdf>
>>
>>
>>
>> rtmp://(ip address)/bcs/channel0_(stream
>> type).bcs?channel=0&stream=0&user=(user name)&password=(user password)
>>
>> The pdf has examples of the stream types and their corresponding
>> stream number. These work for the 410s I have, not sure if they apply
>> to the 410W.
>>
>> James
>>
>>
>>
>> On Sun, Jul 4, 2021 at 11:40 AM Steve <sch...@msn.com
>> <mailto:sch...@msn.com>> wrote:
>>
>> ??? Roger, James, I really appreciate the timely responses. I decided to
>> ??? try
>> ??? rtmp first and found, though Reolink says it works, neither Motion
>> nor
>> ??? VLC could open the stream. Nmap shows port 1935 open.
>>
>> ??? I tried:
>> ??? netcam_url rtmp://<redacted>:1935/h264Preview_01_main
>> ??? netcam_url rtmp://<redacted>/h264Preview_01_main
>>
>> ??? The 410w does a normal TCP connection and then FINs it milliseconds
>> ??? later.
>>
>> ??? -------- Forwarded Message --------
>> ??? Subject: Re: [Motion-user] Reolink 410w video problem
>> ??? Date: Sat, 3 Jul 2021 17:34:19 -0500
>> ??? From: Roger Heflin <roger.hef...@gmail.com
>> ??? <mailto:roger.hef...@gmail.com>>
>> ??? Reply-To: Motion discussion list <motion-user@lists.sourceforge.net
>> ??? <mailto:motion-user@lists.sourceforge.net>>
>> ??? To: Motion discussion list <motion-user@lists.sourceforge.net
>> ??? <mailto:motion-user@lists.sourceforge.net>>
>>
>> ??? On Sat, Jul 3, 2021 at 5:02 PM Roger Heflin <roger.hef...@gmail.com
>> ??? <mailto:roger.hef...@gmail.com>> wrote:
>> ???? >
>> ???? > On Sat, Jul 3, 2021, 2:33 PM Steve <sch...@msn.com
>> ??? <mailto:sch...@msn.com>> wrote:
>> ???? > >
>> ???? > > I've seen this discussed before and checked (wireshark) that
>> ??? the video
>> ???? > > is over TCP yet the "dripping" video persists. The overwhelming
>> ??? majority
>> ???? > > of video files are created by this issue and not "real" motion.
>> ??? It's
>> ???? > > difficult to find the wheat among the chaff.
>> ???? > >
>> ???? > > I see only normal video with VLC but it does lose a few frames
>> ???? > > occasionally. The box running Motion as it's only non-system
>> ??? service is
>> ???? > > a 6-core Core(TM) i7 CPU 990? @ 3.47GHz so lack of processing
>> ??? power is
>> ???? > > not causing the issue.
>> ???? > >
>> ???? >
>> ???? >
>> ???? > Mine are reolink 410 (no W) but using video I get the same issues.
>> ???? > If I turn down the bitrate it works better but it is still not
>> ???? > perfect.
>> ???? >
>> ???? > Since TCP is supposed to retransmit missing frames it might work
>> ???? > better if the window size for the connection was turned down
>> lower.
>> ???? > I am not sure how easy that is to set, but that would reduce the
>> ???? > number of packets sent without an ack.? You might see what the
>> window
>> ???? > is being set to in wireshark.? ? It is claimed that with something
>> ???? > like this:
>> ???? >
>> ???? > iptables -t mangle -A OUTPUT -p tcp --dport 1234 -j TCPWINDOW
>> ???? > --tcpwindow-set 'min(val,100000)'
>> ???? >
>> ???? > You can limit the window size to be whatever you set, smaller
>> ??? would be
>> ???? > better, some quick calcs say with a 4ms ping time, a 8k window
>> size
>> ???? > should be able to handle 16Mbit 1000/4=250? * 8kbytes * 8 =
>> 16mbit.
>> ???? >
>> ???? > Oddly enough using it with the JPEG images I can get 2 or so
>> frames a
>> ???? > second with no packet loss and/or retransmits working
>> correctly.? ?So
>> ???? > it almost must be a poor implementation of rtsp/tcp that really
>> ??? cannot
>> ???? > handle any retransmits at all.? I know with the POE cams I had a
>> ???? > friend that tested it with a direct cable and that did not lose
>> any
>> ???? > packets (typically crossover setup will typically lose no
>> packets but
>> ???? > is hard it implement--1 host port per camera).? ? with wired
>> ???? > networking a "good" cheap network still loses 1 in say 100k
>> packets
>> ???? > when just about any switch is involved, with wireless I would
>> expect
>> ???? > the packet losses to be worse.
>>
>> ??? And thinking about what I just wrote, the reason jpeg works may be
>> ??? that it is a new connection each time such that the connection is
>> ??? never alive long enough for the window size to get out of control
>> ??? and/or too large.
>>
>> ??? I know I have on AIX had to limit the window size (to the manually
>> ??? calculated value based on ping times + known dedicated WAN bandwidth)
>> ??? to get good transmit/streaming rates as their algorithm seem to keep
>> ??? raising the window size until it gets way too large and loses a
>> lot of
>> ??? packets and then it really just seems to give up and never try
>> ??? increasing it again and uses a uselessly small window.? ?So it could
>> ??? simply be that whatever tcp stack they used just plain sucks and had
>> ??? some bad habits around the window size.
>>
>> ??? For the few minutes I watched mine the window size was up to 7100
>> ??? bytes with a scale factor of 3, so 7100*8=56k bytes or so.? And I
>> ??? never saw it go lower it just kept going up, so it may overdo it and
>> ??? that is causing the packet loss.
>>
>>
>> ??? _______________________________________________
>> ??? Motion-user mailing list
>> ??? Motion-user@lists.sourceforge.net
>> ??? <mailto:Motion-user@lists.sourceforge.net>
>> ??? https://lists.sourceforge.net/lists/listinfo/motion-user
>> ??? <https://lists.sourceforge.net/lists/listinfo/motion-user>
>> ??? https://motion-project.github.io/ <https://motion-project.github.io/>
>>
>> ??? Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
>> ??? <https://lists.sourceforge.net/lists/options/motion-user>
>>
>>
>> ??? _______________________________________________
>> ??? Motion-user mailing list
>> ??? Motion-user@lists.sourceforge.net
>> ??? <mailto:Motion-user@lists.sourceforge.net>
>> ??? https://lists.sourceforge.net/lists/listinfo/motion-user
>> ??? <https://lists.sourceforge.net/lists/listinfo/motion-user>
>> ??? https://motion-project.github.io/ <https://motion-project.github.io/>
>>
>> ??? Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
>> ??? <https://lists.sourceforge.net/lists/options/motion-user>
>>
>>
>>
>> --
>> -----BEGIN GEEK CODE BLOCK-----
>> Version: 3.12
>> GIT d? s+:+ a C+++ US++++ P++ L++ E--- W-- N++ o+ K w---
>> O M-- V-- PS PE+ Y+ PGP t+ 5+ X+ R tv+ b+ DI++ D+
>> G e h---- r+++ y++++
>> ------END GEEK CODE BLOCK------
>>
>>
>> _______________________________________________
>> Motion-user mailing list
>> Motion-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/motion-user
>> https://motion-project.github.io/
>>
>> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
>>
>
--
--------------------------------------------------------------------
Steve Schaeffer When all is said and done...
sch...@msn.com there will have been a lot more said than done.
--------------------------------------------------------------------
------------------------------
------------------------------
Subject: Digest Footer
_______________________________________________
Motion-user mailing list
Motion-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/motion-user
------------------------------
End of Motion-user Digest, Vol 181, Issue 5
*******************************************
