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: latest git fails to open netcam (MrDave)
2. Re: latest git fails to open netcam (S Andreason)
3. Re: latest git fails to open netcam (Barry Martin)
----------------------------------------------------------------------
Message: 1
Date: Thu, 29 Jul 2021 22:07:44 -0600
From: MrDave <motionmrd...@gmail.com>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] latest git fails to open netcam
Message-ID: <be37e23a-015f-f48f-204a-064a9d8f2...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Yea, I'll probably add in some defaults back in for the ports.? I just
don't want my perpetual task to be to figure out every protocol that
exists in the world and track down its default port number.
On your problem lagging camera, I've have one of those too.? I don't run
on Pi's anymore so some of the solutions may not work on that platform.?
The items that helped me.
1.? Change the frame rate on the camera (not Motion) to a lower number
2.? Increase the frequency of the I-Frames.
3.? With the latest version, you now have the option 'capture_rate' in
netcam_params which allows you to specify how fast pictures should be
captured from the camera.? The higher the number, the higher the CPU
load but also the more frequent the clearing of the pictures from the
decoder (and therefore lower latency)
On 7/29/2021 9:32 PM, S Andreason wrote:
> Hi Dave,
>
> Documentation, yeah. I could list reasons why I did not look in the
> right places to see the error message earlier this morning...
> $ ./configure --prefix=/usr
> to integrate into existing structure,
> missed the need to also specify --sysconfdir=/etc
> so that the log file would have somewhere to write.
>
> Then when I finally turned off daemon, there were lack of write
> privileges to /var/log/motion.
>
> and $ sudo service motion status keeps too short a list of messages,
> so the important part scrolled off the buffer.
>
> Anyways, specifying port 554 works, and should be a default for
> rtsp:// when not specified. That should be an easy fix.
> So problem fixed.
>
> Moving on to the other camera model that has been the thorn of
> trouble, the reason I sought to see if any motion updates would
> provide fixes.
>
> Prelude: I set up a new pi yesterday, with the raspbian copied from
> the first pi above, and assigned it to one of the Alptop anjvision ip
> cameras. I forgot the camera only worked with older version of motion,
> so didn't check what motion version was running.
> This morning I figured out the stream was 29 seconds behind real time.
> So event_start was triggered long after the actual action happened.
>
> Present: Running today's git version,
> I see some errors in motion.log
> ffmpeg_avcodec_log: error while decoding MB 34 16, bytestream -7
> [2:nc2:204_Alptop_] [INF] [NET] [Jul 29 20:04:31]
> netcam_rtsp_decode_video: Ignoring packet with invalid data
>
> and the delay is still there, although not up to 29 seconds at this time.
> $ ss -t
> State?????? Recv-Q?????? Send-Q???????????? Local
> Address:Port??????????????? Peer Address:Port
> ESTAB?????? 0??????????? 0 192.168.5.124:ftp 192.168.5.119:39748
> ESTAB?????? 29060??????? 0 192.168.5.124:55522 192.168.5.204:rtsp
> ESTAB?????? 0??????????? 0 192.168.5.124:ssh 192.168.5.119:38667
>
> At this time of writing, 20 minutes later, it is up to 4 seconds
> $ ss -t
> State?????? Recv-Q?????? Send-Q???????????? Local
> Address:Port??????????????? Peer Address:Port
> ESTAB?????? 251140?????? 0 192.168.5.124:55522 192.168.5.204:rtsp
> ESTAB?????? 0??????????? 0 192.168.5.124:ftp 192.168.5.119:37316
> ESTAB?????? 0??????????? 0 192.168.5.124:ssh 192.168.5.119:38667
>
> I have a log_level=9 file to offer.
> I'll revert the motion version to 2020-10-26 for now.
>
> Any hope of getting the stream to stay with real-time?
>
>
>
> MrDave wrote:
>> I think the revision I pushed last night may be tripping it up but
>> I'm not quite ready to revoke it.? (I may however add additional
>> documentation)
>>
>> Motion historically restricted the protocols that it would support
>> and many issues have been raised regarding expanding the list. The
>> revision removed the restriction on what is supported and leaves it
>> open to the user to specify the right URI.? So it will now support
>> http, https, rtsp, rtsps, etc, etc.? Whatever ffmpeg supports, Motion
>> just passes the URI along to ffmpeg. BUT.....in order to do this, the
>> default ports become a problem. There is no longer a fixed list of
>> protocols.
>>
>> So from looking at your log, it seems that you may need to put in
>> 554, 80 or something else into your netcam_url string so it addresses
>> the message
>>
>> [1:ml1:205_HikVisi] [INF] [ENC] [Jul 29 14:12:30] ffmpeg_avcodec_log:
>> Port missing in uri
>>
>>
>> Dave
>>
>> On 7/29/2021 3:59 PM, S Andreason wrote:
>>> Disregard my last email. After 5 hours of working on this, of course
>>> it is after sending an email that I discover the problem.... turned
>>> off daemon mode, got lots of write permission errors, but finally
>>> could see something helpful:
>>>
>>> "videodevice" replaced with "video_device" after version 4.3.2
>>>
>>> Another hour plus later, I'm still unable to get motion to work,
>>> from motion.log
>>>
>>> [1:ml1:205_HikVisi] [NTC] [VID] [Jul 29 14:12:30] vid_start: Opening
>>> Netcam RTSP
>>> [1:ml1:205_HikVisi] [INF] [NET] [Jul 29 14:12:30]
>>> netcam_rtsp_set_parms: Setting up norm stream.
>>> [1:ml1:205_HikVisi] [INF] [ALL] [Jul 29 14:12:30] util_parms_add:
>>> Parsed: >decoder< >NULL<
>>> [1:ml1:205_HikVisi] [INF] [NET] [Jul 29 14:12:30]
>>> netcam_rtsp_set_path: Setting up rtsp via netcam
>>> [1:ml1:205_HikVisi] [INF] [NET] [Jul 29 14:12:30]
>>> netcam_rtsp_set_options: norm: Setting rtsp/rtmp
>>> [1:ml1:205_HikVisi] [INF] [ALL] [Jul 29 14:12:30] util_parms_add:
>>> Parsed: >rtsp_transport< >tcp<
>>> [1:ml1:205_HikVisi] [INF] [ALL] [Jul 29 14:12:30] util_parms_add:
>>> Parsed: >allowed_media_types< >video<
>>> [1:ml1:205_HikVisi] [INF] [NET] [Jul 29 14:12:30]
>>> netcam_rtsp_set_options: norm: option: rtsp_transport = tcp
>>> [1:ml1:205_HikVisi] [INF] [NET] [Jul 29 14:12:30]
>>> netcam_rtsp_set_options: norm: option: allowed_media_types = video
>>> [1:ml1:205_HikVisi] [INF] [ENC] [Jul 29 14:12:30]
>>> ffmpeg_avcodec_log: Port missing in uri
>>> [1:ml1:205_HikVisi] [ERR] [NET] [Jul 29 14:12:30]
>>> netcam_rtsp_open_context: norm: Unable to open
>>> camera(205_HikVision_N): Invalid argument
>>> [1:ml1:205_HikVisi] [INF] [NET] [Jul 29 14:12:30]
>>> netcam_rtsp_cleanup: norm: Shutting down network camera.
>>> [1:ml1:205_HikVisi] [NTC] [NET] [Jul 29 14:12:30]
>>> netcam_rtsp_cleanup: Normal resolution: Shut down complete.
>>> [1:ml1:205_HikVisi] [ERR] [VID] [Jul 29 14:12:30] vid_start: Netcam
>>> RTSP failed to open
>>>
>>>
>>> S Andreason wrote:
>>>> /etc/motion/motion.conf does have the lines:
>>>> videodevice netcam
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
>
> _______________________________________________
> 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: Thu, 29 Jul 2021 21:40:32 -0700
From: S Andreason <sandrea...@gmail.com>
To: Motion-user <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] latest git fails to open netcam
Message-ID: <2b055351-b12b-8f2e-9eed-7c7cd529f...@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
This new pi is only running the one camera, so cpu load should not be a
factor.
1. already 15 fps
2. 60 = 2 seconds
3. So that's why the default chosen was 16, instead of 15. ok. I'll go
back to a testing stance.
Also, as per murphy's law, the Recv-Q is now 0. The only thing I can see
that changed, is day turned to dusk. I'll see what tomorrow brings.
Thanks.
MrDave wrote:
> Yea, I'll probably add in some defaults back in for the ports.? I just
> don't want my perpetual task to be to figure out every protocol that
> exists in the world and track down its default port number.
>
> On your problem lagging camera, I've have one of those too.? I don't
> run on Pi's anymore so some of the solutions may not work on that
> platform.? The items that helped me.
>
> 1.? Change the frame rate on the camera (not Motion) to a lower number
>
> 2.? Increase the frequency of the I-Frames.
>
> 3.? With the latest version, you now have the option 'capture_rate' in
> netcam_params which allows you to specify how fast pictures should be
> captured from the camera.? The higher the number, the higher the CPU
> load but also the more frequent the clearing of the pictures from the
> decoder (and therefore lower latency)
>
------------------------------
Message: 3
Date: Fri, 30 Jul 2021 08:01:35 -0500
From: Barry Martin <barry3mar...@gmail.com>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] latest git fails to open netcam
Message-ID: <9c8be29e-f5ad-935d-40b9-a8b67f93c...@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 7/29/21 11:40 PM, S Andreason wrote:
> This new pi is only running the one camera, so cpu load should not be
> a factor.
> 1. already 15 fps
> 2. 60 = 2 seconds
> 3. So that's why the default chosen was 16, instead of 15. ok. I'll go
> back to a testing stance.
> Also, as per murphy's law, the Recv-Q is now 0. The only thing I can
> see that changed, is day turned to dusk. I'll see what tomorrow brings.
S,:
If it's a Raspberry Pi 4 keep the GPU_Mem _low_ -- to me
counter-intuitive when have a video problem but read that over in the
Raspberry Pi forums.? I have an RPi 4 (4 GB version) with two USB
cameras and it is configured to 128 MB and I could probably go with
less.? Higher memory caused all sorts of issues, possibly because I was
'starving' the ARM.? Appears there is 1 GB shared between the two and
what one uses the other can't.
??? pi@raspberrypi:~ $ vcgencmd get_mem gpu
??? gpu=128M
??? pi@raspberrypi:~ $ vcgencmd get_mem arm
??? arm=896M
HTH!
Barry
-------------- 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 19
********************************************
