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. Re: Reolink 410w video problem (Steve)
2. Re: Fwd: Reolink 410w video problem (mar...@savcom.co.uk)
----------------------------------------------------------------------
Message: 1
Date: Sat, 3 Jul 2021 20:45:23 -0600
From: Steve <sch...@msn.com>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Reolink 410w video problem
Message-ID:
<by3pr08mb712343abe710127e583cc8cac5...@by3pr08mb7123.namprd08.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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.
--------------------------------------------------------------------
------------------------------
Message: 2
Date: Sun, 4 Jul 2021 12:08:46 +0100
From: <mar...@savcom.co.uk>
To: "'Motion discussion list'" <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Fwd: Reolink 410w video problem
Message-ID: <00d301d770c4$f5f16d60$e1d44820$@savcom.co.uk>
Content-Type: text/plain; charset="utf-8"
James
I have this camera ? but didn?t know I had this problem! Thank you for the
link to Reolink?s guide. Very useful indeed.
Martin
From: James Smith <gry...@gmail.com>
Sent: 04 July 2021 02:53
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Fwd: Reolink 410w video problem
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://motion-project.github.io/
Unsubscribe: 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://motion-project.github.io/
Unsubscribe: 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------
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------
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 3
*******************************************
