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. Reolink 410w video problem (Steve)
2. Re: Reolink 410w video problem (Roger Heflin)
3. Re: Reolink 410w video problem (James Smith)
4. Re: Reolink 410w video problem (Roger Heflin)
----------------------------------------------------------------------
Message: 1
Date: Sat, 3 Jul 2021 13:17:50 -0600
From: Steve <sch...@msn.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: [Motion-user] Reolink 410w video problem
Message-ID:
<by3pr08mb712352ec42693b58d2d7c78dc5...@by3pr08mb7123.namprd08.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
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.
There are 2 Netgear Nighthawk R7900p access points with 802.11ac and
they, the server, and all 6 cams (4 are Reolink) are connected via an
unmanaged 1000baseT/Full switch so that's not the problem (besides, VLC
is on a box through a router and 2 more switches and not having a problem).
I *think* these are the only config lines you'll want to see:
movie_quality 75
netcam_use_tcp on
netcam_url rtsp://<redacted>:554//h264Preview_01_main
width 1920
height 1072
framerate 10 (VLC is getting 30)
despeckle_filter EedDl
noise_tune on
threshold_tune on
Here is the codec info from VLC:
Stream 0
Codec: H264 - MPEG-4 AVC (part 10) (h264)
Type: Video
Video resolution: 1920x1072
Buffer dimensions: 1920x1072
Frame rate: 29.970030
Decoded format:
Orientation: Top left
Stream 1
Codec: MPEG AAC Audio (mp4a)
Type: Audio
Channels: Stereo
Sample rate: 32000 Hz
Bits per sample: 32
I'm really hoping that new information has come to light or that I
missed something from the previous discussions and someone can help cure
this.
Thanks for your time.
--
--------------------------------------------------------------------
Steve Schaeffer When all is said and done...
sch...@msn.com there will have been a lot more said than done.
--------------------------------------------------------------------
------------------------------
Message: 2
Date: Sat, 3 Jul 2021 17:02:59 -0500
From: Roger Heflin <roger.hef...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Reolink 410w video problem
Message-ID:
<CAAMCDefUvxoL+9FXS2kMLRPieHeL315WpwxuJ8__K2UMxv=N=w...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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.
------------------------------
Message: 3
Date: Sun, 4 Jul 2021 08:19:37 +1000
From: James Smith <gry...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Reolink 410w video problem
Message-ID:
<CAK21x7t3h148jJTsMtXabY6vUGBVv+L3E=7uisvx+noasof...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Have you tried configuring to use RTMP? I'd read somewhere that the 410s
have a bug in their RTSP code, have both mine set up for the RTMP stream
and only get the occasional artifact.
James
On Sun, 4 Jul 2021, 05:34 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.
>
> There are 2 Netgear Nighthawk R7900p access points with 802.11ac and
> they, the server, and all 6 cams (4 are Reolink) are connected via an
> unmanaged 1000baseT/Full switch so that's not the problem (besides, VLC
> is on a box through a router and 2 more switches and not having a problem).
>
> I *think* these are the only config lines you'll want to see:
> movie_quality 75
> netcam_use_tcp on
> netcam_url rtsp://<redacted>:554//h264Preview_01_main
> width 1920
> height 1072
> framerate 10 (VLC is getting 30)
> despeckle_filter EedDl
> noise_tune on
> threshold_tune on
>
> Here is the codec info from VLC:
> Stream 0
> Codec: H264 - MPEG-4 AVC (part 10) (h264)
> Type: Video
> Video resolution: 1920x1072
> Buffer dimensions: 1920x1072
> Frame rate: 29.970030
> Decoded format:
> Orientation: Top left
> Stream 1
> Codec: MPEG AAC Audio (mp4a)
> Type: Audio
> Channels: Stereo
> Sample rate: 32000 Hz
> Bits per sample: 32
>
> I'm really hoping that new information has come to light or that I
> missed something from the previous discussions and someone can help cure
> this.
>
> Thanks for your time.
> --
> --------------------------------------------------------------------
> Steve Schaeffer When all is said and done...
> sch...@msn.com there will have been a lot more said than done.
> --------------------------------------------------------------------
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 4
Date: Sat, 3 Jul 2021 17:34:19 -0500
From: Roger Heflin <roger.hef...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Reolink 410w video problem
Message-ID:
<caamcdefuuepm4d3biew86efzv1azrktcazneksriconwoya...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
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.
------------------------------
------------------------------
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 1
*******************************************
