M3u playlist / ip camera slow

The M3U playlist format is well documented. It traces its lineage all the way back to the WinAmp days.

(You may want to change the initial 0 in your playlist to -1 if "malformed" is an issue. That number specifies the duration of the stream, and -1 means indeterminate/none for the duration, which is what it should be for continuous live streams.)

1 Like

I haven't tested this but have experience using RTSP on other devices such as touchpanels on my automation system and streams for multiple cameras and one thing I noticed with lagging streams was the device that was playing back the stream, is it a RPI or a Windows machine etc?

Also with many cameras you can choose from a Primary or Sub-stream and is you are. using the Primary stream and its 4K or 1080 then see if you have a Sub-stream URL you can use?

This will be a lower quality stream URL but still good enough for viewing, your cameras when properly configured with most NVR's will record in the highest resolution but you should limit your access to lower quality streams when viewing for a better experience, and of course you can choose to do whatever you want but you may get a better experience testing with a sub-stream if you can.

As an example most Ubiquiti cameras have High,Medium,Low streams for RTSP you can choose and beside this you can also adjust bitrate and as an example when using the AppleTV app I can have access to all 14 of my cameras and get a small video preview window of them all at once and then I can click any of them and see a good quality full screen image.

I think part of the reason it might stream efficiently with their app is related to the quality of the stream they allow to the app which I think is the low RTSP stream and as well as the keyframe rate which they set to 0.20 when using the cameras with the Ubiquiti Protect system and their Cloudkey Gen2+

**Another thing worth mentioning, in the past I have used this setup with RPI Gen3 and had 8 cameras onscreen at once and it was using omx player on the PI, is it possible for Channels App to use Omx to play back URL's if having problems?

https://community.ui.com/questions/Tutorial-Raspberry-Pi-4-Cam-Matrix-Viewer-Appliance/f28e9841-4971-452b-820b-64af4385efbb

I have several Unifi Cameras and each have there own RSTP stream. Interestingly, when I place the RSTP stream into the txt option, the stream plays, but only the top quarter is clear with the bottom 3 quarters blurred out. When I choose the medium quality stream, it will show the top half of the screen clearly. Choosing the lowest quality stream, it will show the top 3 quarters of the stream clearly, with the bottom quarter still blurred. Logs show the following:

2020/12/28 21:28:20.763387 [HLS] ffmpeg: rtsp-Front Door: [rtsp @ 0x236a4f50] max delay reached. need to consume packet
2020/12/28 21:28:20.763430 [HLS] ffmpeg: rtsp-Front Door: [rtsp @ 0x236a4f50] RTP: missed 30 packets

@tmm1 Using the custom tags to choose a channel logo, I was looking for a way to host a local image without setting up a separate web service. I attempted to look options for dropping an image in the data folder but the preview and error png files seem to be specific to what was coded to the DB and subject to change/delete. It would be nice to have an image directory we could use for uploading custom image files instead of referencing an http source that may change.

Same here — just switched to UniFi Protect and either I get vertical bars in the bottom portion of the video or just all black, with errors:

2020/12/28 13:32:09.588372 [HLS] Starting transcoder for channel 2000 from [...] (encoder=remux, resolution=, deinterlacer=, bitrate=0)
2020/12/28 13:32:09.924460 [HLS] ffmpeg: rtsp-Front Camera:  [rtsp @ 0x2bf1f40] max delay reached. need to consume packet
2020/12/28 13:32:09.924510 [HLS] ffmpeg: rtsp-Front Camera:  [rtsp @ 0x2bf1f40] RTP: missed 227 packets
2020/12/28 13:32:09.955081 [HLS] ffmpeg: rtsp-Front Camera:  [h264 @ 0x2bf8a40] error while decoding MB 64 28, bytestream -45
2020/12/28 13:32:10.732968 [HLS] ffmpeg: ch2000-dANY-b1b7d4ee9237-remux:  [h264 @ 0x2884f00] error while decoding MB 64 28, bytestream -46
2020/12/28 13:32:10.972927 [HLS] Probed live stream in 1.384343284s: h264 1920x1080 progressive 4222915bps
2020/12/28 13:32:14.809031 [HLS] Session ch2000-dANY-b1b7d4ee9237 started in 5.222206553s
2020/12/28 13:32:35.212225 [HLS] Stopping transcoder session ch2000-dANY-b1b7d4ee9237 (out: 25.449067s, finished: false)
2020/12/28 13:32:35.212337 [ERR] Error during stream M3U-UniFiProtect ch2000 Front Camera: read |0: file already closed
2020/12/28 13:32:35.212363 [TNR] Closed connection to M3U-UniFiProtect for ch2000 Front Camera
2020/12/28 13:32:35.224177 [HLS] ffmpeg: rtsp-Front Camera:  av_interleaved_write_frame(): Broken pipe
2020/12/28 13:32:35.224272 [HLS] ffmpeg: rtsp-Front Camera:  Error writing trailer of pipe:: Broken pipe

I also set up the Homebridge plugin, and it seems to do OK streaming to HomeKit on iOS either rebroadcasting or transcoding (using ffmpeg). I wonder if there’s something it’s doing that Channels could do. Here’s the streaming code if it is helpful.

Does it work correctly in VLC ?

Yes it also works fine in VLC — that’s what I had been using on the Apple TV previously but it’d be nice to have it all integrated in Channels!

Mine also works great with vlc.... Sucks in channels

concur...works in VLC without issue.

If someone can give me SSH/VPN access to their network so I can connect to the camera and try some stuff, that would be helpful. Sounds like ffmpeg's RTSP support is not handling this camera correctly.

Alternatively wireshark capture of VLC streaming correctly would help as well.

I have UVC G3’s working fine in Channels. Occasionally, the bottom quarter of the screen is scrambled but this clears up as soon as the timeline disappears in channels.

You mentioned HLS, I use MPEG-TS.

Can you share your text?

1 Like

I have a G4 Doorbell cam and several G3 Flex cams. It happens on all of them. Here is one of my G3 flex cam txt that I use with MPEG-TS.

#EXTM3U
#EXTINF:-1 channel-id="Driveway" channel-number="1.2" tvg-logo="https://unifi-protect.ui.com/static/media/device.a43793a8.png" tvg-name="Unifi Protect" tvc-guide-title="Driveway" tvc-guide-description="Unifi Protect G3 Flex Camera" tvc-guide-art="https://unifi-protect.ui.com/static/media/device.a43793a8.png",
rtsp://192.168.10.14:7447/uXBYPrlsN0PEb2Bw

OK, so what is at 192.168.10.14? Is that UniFi Protect?

For reference this is mine:

#EXTM3U

#EXTINF:-1 channel-id="UVC G3" channel-number="8001" tvg-logo="http://ubuntu/camera.jpg" tvg-name="UVC G3" tvc-guide-title="Driveway Cam" tvc-guide-description="Comings and goings" tvc-guide-art="http://ubuntu/Driveway.png",UVC G3

rtsp://192.168.1.1:7447/WsPibtgrhIEF6gV7

That is my internal IP for the Unifi Cloud Key Gen2 plus.

In my case it’s Unifi Protect running on a UDM Pro. So, other than the host hardware/software (which could be a big deal), the other difference I see is I am hosting the logo and art locally. Also, did you mention using HLS vs MPEG-TS?

1 Like

I am using MPEG-TS. If it was hardware, I would expect the same behavior in HomeBridge/HomeKit, but these work fine as does VLC.

1 Like

Not so sure. Homebridge/HomeKit, which I also use, serves a new image every 10 secs not a live stream (unless you click into the stream itself). So, it could be that the extra CPU in the UDM Pro vs the CloudKey is making a difference. I do recall back when I had a CloudKey that the streaming did not work very well. This was a few years ago though and many other factors have changed since then.

Homekit provides a snapshot every 10sec and less so for uncertified accessories. I dont find homekit streaming all that robust whether it is for supported accessories or whilst using home bridge. This also seems independent of the platform in the case of home bridge and resources. I just think it is still in its early days.