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. Fwd: Reolink 410w video problem (Steve)
2. Re: Fwd: Reolink 410w video problem (James Smith)
----------------------------------------------------------------------
Message: 1
Date: Sat, 3 Jul 2021 19:39:01 -0600
From: Steve <sch...@msn.com>
To: motion-user@lists.sourceforge.net
Subject: [Motion-user] Fwd: Reolink 410w video problem
Message-ID:
<by3pr08mb7123bce681aca0108b112b9dc5...@by3pr08mb7123.namprd08.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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>
Reply-To: Motion discussion list <motion-user@lists.sourceforge.net>
To: Motion discussion list <motion-user@lists.sourceforge.net>
On Sat, Jul 3, 2021 at 5:02 PM Roger Heflin <roger.hef...@gmail.com> wrote:
>
> On Sat, Jul 3, 2021, 2:33 PM Steve <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
https://lists.sourceforge.net/lists/listinfo/motion-user
https://motion-project.github.io/
Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
------------------------------
Message: 2
Date: Sun, 4 Jul 2021 11:53:25 +1000
From: James Smith <gry...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Fwd: Reolink 410w video problem
Message-ID:
<CAK21x7sVnQETyMkOLgbyHLo=qwBHejOnYsicM0W=e_wxojz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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> 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>
> Reply-To: Motion discussion list <motion-user@lists.sourceforge.net>
> To: Motion discussion list <motion-user@lists.sourceforge.net>
>
> On Sat, Jul 3, 2021 at 5:02 PM Roger Heflin <roger.hef...@gmail.com>
> wrote:
> >
> > On Sat, Jul 3, 2021, 2:33 PM Steve <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
> 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
> 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 2
*******************************************
