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: Image Corruption on RTSP streams (Colin Law)
2. Re: Image Corruption on RTSP streams (tosiara)
3. Re: Image Corruption on RTSP streams (David Powell)
4. Re: Image Corruption on RTSP streams (greg thomas)
----------------------------------------------------------------------
Message: 1
Date: Mon, 7 Jan 2019 07:39:28 +0000
From: Colin Law <clan...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Image Corruption on RTSP streams
Message-ID:
<CAL=0gltpv2oftgke6fegapgrem6gt95v1fx5buqbov4wapf...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Mon, 7 Jan 2019 at 02:49, greg thomas <geete...@gmail.com> wrote:
>
> Hello,
> I have a Raspberry Pi 3B running Debian Stretch kernel with Motion 4.1.1
> with two network cameras. Everything is connected via wired Ethernet, and the
> cameras are set to use TCP. The cameras are 1M pxiel cameras, and sending
> 10fps.
>
> On the stream feeds I get image corruption as shown in the attachments.
Have you run 'top' on the pi to make sure that it is up to the job?
RTSP is heavy on processor load as it has to decode every frame coming
in, even if you don't want them all. If possible configure the
cameras to stream the smallest image size and frame rate that is
enough for your purpose.
Are you viewing the corrupted stream on the pi or on another machine?
Viewing video can also be very heavy on processor usage.
Colin
> I looks as if the image corruption is actually an overlay as the underlying
> image is generally still visible, albeit somewhat blurred. It looks like a
> chromatic issue, rather than a dropped packet issue. I have set the iframe
> interval to between 2 and 20 to try and force a full frame to be sent, but it
> makes no difference. I've tried changing the fps, up and down, and it makes
> no difference. I am running these through Motion-Eye, and have also tried
> MiotionEyeOS, both make no difference. I can connect to the stream via VLC,
> and the images are 100% clean. I connect to the cameras via the CMS software,
> and the images are also clean.
>
> Any thoughts on this please?
>
> Regards
>
> Greg
> _______________________________________________
> 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: Mon, 7 Jan 2019 10:36:45 +0200
From: tosiara <tosi...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Image Corruption on RTSP streams
Message-ID:
<cachtdwtor6kgq6nab0co0jrgwt6kuwr+wzxe4poizy49zjd...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Are you using UDP RTSP?
On Mon, Jan 7, 2019 at 4:49 AM greg thomas <geete...@gmail.com> wrote:
>
> Hello,
> I have a Raspberry Pi 3B running Debian Stretch kernel with Motion 4.1.1
> with two network cameras. Everything is connected via wired Ethernet, and the
> cameras are set to use TCP. The cameras are 1M pxiel cameras, and sending
> 10fps.
>
> On the stream feeds I get image corruption as shown in the attachments.
> I looks as if the image corruption is actually an overlay as the underlying
> image is generally still visible, albeit somewhat blurred. It looks like a
> chromatic issue, rather than a dropped packet issue. I have set the iframe
> interval to between 2 and 20 to try and force a full frame to be sent, but it
> makes no difference. I've tried changing the fps, up and down, and it makes
> no difference. I am running these through Motion-Eye, and have also tried
> MiotionEyeOS, both make no difference. I can connect to the stream via VLC,
> and the images are 100% clean. I connect to the cameras via the CMS software,
> and the images are also clean.
>
> Any thoughts on this please?
>
> Regards
>
> Greg
> _______________________________________________
> 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: 3
Date: Mon, 7 Jan 2019 03:57:31 -0500
From: David Powell <da...@depowell.com>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Image Corruption on RTSP streams
Message-ID: <0f7d44ea-f5d6-8cee-afd6-8ae274885...@depowell.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
I have the same issue on my RPi.? It only happens with RTSP streams, and
only intermittently.? The same streams look fine when viewed with a
different viewer, like ffplay or VLC.? Like you, I have not been able to
determine a cause, but the problem is almost certainly within Motion
somewhere.? When the corruption occurs, a movie is recorded and the
corruption is visible in the movie.
I would be very interested in the solution if you find it.
David
On 1/6/19 9:47 PM, greg thomas wrote:
> Hello,
> ? ?I have a Raspberry Pi 3B running Debian Stretch kernel with Motion
> 4.1.1 with two network cameras. Everything is connected via wired
> Ethernet, and the cameras are set to use TCP. The cameras are 1M pxiel
> cameras, and sending 10fps.
>
> On the stream feeds I get image corruption as shown in the attachments.
> I looks as if the image corruption is actually an overlay as the
> underlying image is generally still visible, albeit somewhat blurred.
> It looks like a chromatic issue, rather than a dropped packet issue. I
> have set the iframe interval to between 2 and 20 to try and force a
> full frame to be sent, but it makes no difference. I've tried changing
> the fps, up and down, and it makes no difference.?I am running these
> through Motion-Eye, and have also tried MiotionEyeOS, both make no
> difference. I can connect to the stream via VLC, and the images are
> 100% clean. I connect to the cameras via the CMS software, and the
> images are also clean.
>
> Any thoughts on this please?
>
> Regards
>
> Greg
>
>
> _______________________________________________
> 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: Mon, 7 Jan 2019 22:07:31 +1300
From: greg thomas <geete...@gmail.com>
To: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Image Corruption on RTSP streams
Message-ID:
<cage5y2fdyxynrhdtnh0pq0thh6uvqqj3x+fy5pd0bcjjfxj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The Pi it's running around 35-40% utilisation, so I don't think it's a
processor constraint. That said I still do not know what the cause is.
I know the corruption affects both cameras in the same way in color or
black and white/IR, and it only seems to impact the bottom 1/3ish of the
image.
Regards
Greg
On Mon, 7 Jan 2019, 8:40 PM Colin Law <clan...@gmail.com wrote:
> On Mon, 7 Jan 2019 at 02:49, greg thomas <geete...@gmail.com> wrote:
> >
> > Hello,
> > I have a Raspberry Pi 3B running Debian Stretch kernel with Motion
> 4.1.1 with two network cameras. Everything is connected via wired Ethernet,
> and the cameras are set to use TCP. The cameras are 1M pxiel cameras, and
> sending 10fps.
> >
> > On the stream feeds I get image corruption as shown in the attachments.
>
> Have you run 'top' on the pi to make sure that it is up to the job?
> RTSP is heavy on processor load as it has to decode every frame coming
> in, even if you don't want them all. If possible configure the
> cameras to stream the smallest image size and frame rate that is
> enough for your purpose.
> Are you viewing the corrupted stream on the pi or on another machine?
> Viewing video can also be very heavy on processor usage.
>
> Colin
>
> > I looks as if the image corruption is actually an overlay as the
> underlying image is generally still visible, albeit somewhat blurred. It
> looks like a chromatic issue, rather than a dropped packet issue. I have
> set the iframe interval to between 2 and 20 to try and force a full frame
> to be sent, but it makes no difference. I've tried changing the fps, up and
> down, and it makes no difference. I am running these through Motion-Eye,
> and have also tried MiotionEyeOS, both make no difference. I can connect to
> the stream via VLC, and the images are 100% clean. I connect to the cameras
> via the CMS software, and the images are also clean.
> >
> > Any thoughts on this please?
> >
> > Regards
> >
> > Greg
> > _______________________________________________
> > 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
>
-------------- 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 151, Issue 9
*******************************************
