So I am not sure where to start on this. After playing around I have my doorbell camera imported as a source using rtsp:// and works.
When I tune the channel via a tv or app or the webpage, it takes about 20 seconds before I get a picture. If I put the same url into vlc, it shows almost instantaneously..
Is there anything I can tune to speed this up?
Diagnostics from the dvr would be good first step.
What is the model of the camera?
Well, I tuned the channel, then submitted diags. The camera is an hikvision nsc-db1.
Let me know...
Thanks
I noted many errors in the logs, do they tell you anything?
Kind of. We still have a lot of learn about RTSP since this is something new we are trying to support.
Happy to provide my text entry if it helps. Would like to see someone at the door before they leave 
This is probably a setup issue on my end as I have zero experience and have been piecing together things to make it work. Here is my text entry and some of the errors I see:
#EXTM3U
#EXTINF:0,Front Door Camera
rtsp://syno:[email protected]:554/Sms=3.unicast
#EXT-X-ENDLIST
2020/12/11 11:34:32.060304 [TNR] Opened connection to M3U-FrontDoor Camera for ch9000 Front Door Camera [transcode=none]
2020/12/11 11:34:34.037388 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:34:34.037446 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 13 packets
2020/12/11 11:34:34.064717 [HLS] ffmpeg: rtsp-idx-0: [h264 @ 0x2e5d880] error while decoding MB 107 55, bytestream -9
2020/12/11 11:34:34.198401 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:34:34.198527 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 20 packets
2020/12/11 11:34:34.227099 [HLS] ffmpeg: rtsp-idx-0: [h264 @ 0x2e5d880] error while decoding MB 88 49, bytestream -17
2020/12/11 11:34:36.197408 [HLS] ffmpeg: rtsp-idx-0: Guessed Channel Layout for Input Stream #0.1 : mono
2020/12/11 11:34:36.197784 [HLS] ffmpeg: rtsp-idx-0: [mpegts @ 0x2eae500] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
2020/12/11 11:34:39.155754 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:34:39.155809 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 12 packets
2020/12/11 11:34:54.164141 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:34:54.164203 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 12 packets
2020/12/11 11:34:56.685593 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:34:56.685665 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 22 packets
2020/12/11 11:34:59.141610 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:34:59.141673 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 22 packets
2020/12/11 11:35:01.691237 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:35:01.691291 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 12 packets
2020/12/11 11:35:36.676400 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:35:36.676457 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 13 packets
2020/12/11 11:35:39.542953 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:35:39.543010 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 23 packets
2020/12/11 11:35:41.897674 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:35:41.897730 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 20 packets
2020/12/11 11:35:44.498171 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:35:44.498244 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 23 packets
2020/12/11 11:35:46.753564 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:35:46.753617 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 21 packets
2020/12/11 11:35:49.153966 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:35:49.154026 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 23 packets
2020/12/11 11:35:51.915463 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:35:51.915515 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 20 packets
2020/12/11 11:35:54.174907 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:35:54.174964 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 16 packets
2020/12/11 11:35:56.665789 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] max delay reached. need to consume packet
2020/12/11 11:35:56.665852 [HLS] ffmpeg: rtsp-idx-0: [rtsp @ 0x2e59f40] RTP: missed 14 packets
2020/12/11 11:36:07.190230 [ERR] Error during stream M3U-FrontDoor Camera ch9000 Front Door Camera: read |0: file already closed
2020/12/11 11:36:07.190294 [TNR] Closed connection to M3U-FrontDoor Camera for ch9000 Front Door Camera
2020/12/11 11:36:07.351413 [HLS] ffmpeg: rtsp-idx-0: av_interleaved_write_frame(): Broken pipe
2020/12/11 11:36:07.351469 [HLS] ffmpeg: rtsp-idx-0: Error writing trailer of pipe:: Broken pipe
So should I just give up on this?
I just imported my Amcrest camera using RTSP with a M3U – no real issues to report. It works quite well, with only about a 2-3 second lag in tuning into the stream.
Can you post your format and what you did?
I added mine as rtsp as well, but have about a 25-30 second lag and it takes about 15 seconds to start the video feed from the guide.
Any tips you can offer?
Submit diags and keep this thread going. I think my request has fallen by the wayside...the more reporting the better!
My M3U contains the following:
#EXTM3U
#EXTINF:0,{camera-name}
rtsp://username:password@<internal_ip_address>:554
#EXT-X-ENDLIST
The time to 'tune' into the stream is slightly over 3 seconds (informally measured at 3.28s on iOS, and 3.18s on AndroidTV).
When importing the M3U into Channels setup, I chose MPEG-TS as the format (everything else left at default). Channels server (version 2020.12.11.0338) is running on macOS 10.15.7, Apache is 2.4.46 (port 80), and camera is IP2M-841W model running sw V2.420.AC00.18.R, Build Date: 2020-02-17. Are you running a separate web server service?
Good luck.
Sorry, I am not sure what you mean by that. I run a synology NAS with channels DVR installed. My camera is added to the surveillance station (synology software) and I access the stream from there. I have also tried directly to the camera and the results are the same... 20+ second delay.
Thanks.
By this, I mean that for instance my camera's IP is 192.168.1.10. I can access the stream directly through RTSP clients at this address. But since I need to use a M3U, the web server (macOS-based) hosting the actual M3U for instance is 192.168.1.20. So when I point Channels to the M3U, it is pointed to the M3U that is hosted on the .20 intranet web server.
Whether that has something to do with the difference in delay, I am not sure. It also could just be the something to do Synology... I don't have Synology, but do have a number of QNAPs that I could test this on as well. If I get the opportunity later tonight, I'll run a test from there to see if there is a performance difference.
I think I see what you are saying. Well, when I defined the stream, I used the text option and entered the below text... I assume that means the m3u is local to the dvr install yes?
#EXTM3U
#EXTINF:0,Front Door Camera
rtsp://syno:[email protected]:554/Sms=3.unicast
#EXT-X-ENDLIST
Some cameras work great, others lag and have issues. I'm not going to go buy every camera on the market, so this feature is currently "as-is".
That said if someone wants to give me VPN access to their network so I can connect to a problematic camera and investigate, I am happy to do that.
Do you have any doorbell cameras you do recommend?
I didn't previously compare your log to mine, but doing so now I see one pretty big difference:
2020/12/13 23:14:25.325338 [TNR] Opened connection to M3U-Amcrest for ch9000
Camera Room
2020/12/13 23:14:27.945435 [HLS] ffmpeg: rtsp-idx-0: [mpegts @ 0x7f9306840000] Non-monotonous DTS in output stream 0:0; previous: 54300, current: 24300; changing to 54301. This may result in incorrect timestamps in the output file.
2020/12/13 23:14:27.945455 [HLS] ffmpeg: rtsp-idx-0: [mpegts @ 0x7f9306840000] Non-monotonous DTS in output stream 0:0; previous: 54301, current: 30600; changing to 54302. This may result in incorrect timestamps in the output file.
As previously alluded, I imported my camera via Add Source > M3U Playlist > MPEG-TS + URL of intranet-hosted M3U file. I don't know enough about how Channels is accessing your stream, but if it is using your native RTSP source and then having to convert it to segmented HLS at 10 second chunks, then that could easily explain the latency. Most HLS clients by default want to buffer 3 segments, so at 10 seconds per segment, that would be a 30 second delay, which is what you are experiencing.
Curiously, what are the video and audio codecs you are using for your camera? Using H264 and AAC here...
I am new to this community and my first venture was to setup my EZVIZ Doorbell Camera. I created a M3U file with the following lines:
#EXTM3U
#EXTINF:0,Front Door Camera
Rtsp://username:[email protected].?.?:554/H.264
It worked in VLC, but not in Channels DVR. I worked on this for hours, but kept getting malformed M3U file in the logs. I finally ran across this community and noticed some of the people used an end statement. I added #EXT-X-ENDLIST and my camera feed began to work. I’m happy it worked but I just don’t understand why. In most programming languages the # symbol is used for comments. Can anyone explain this for my future endeavors?