RTSP Video Feed Distortion. Multiple sources / feeds tested. Not a problem in VLC

[halfspec]

Overview of the Issue

My problem is that when adding a rtsp video feed as an asset in Screenly OSE, the output has distortion that comes and goes. Here's an example coming from a Hikvision surveillance camera:

Distortion: http://www.halfspec.com/pictures/20190111_094917.jpg No Distortion: http://www.halfspec.com/pictures/20190111_094834.jpg

It's only rtsp feeds and it happens on both raspberry pi's on multiple TVs I've tried. Still images and videos that are uploaded as assets play perfectly. Additionally, I've tried multiple rtsp feeds. The feed above comes from a surveillance camera but here's a shot of the same type of distortion coming from a video encoder to rtsp feed converter box (fmuser):

Distortion 2: http://www.halfspec.com/pictures/20190111_095128.jpg

Note - The streaking / distortion doesn't always take up 1/2 the screen as shown in my pictures. A lot of times, it's just 10% vertical bar across the bottom.

I have tried changing the rtsp feed resolutions all the way down to 640x480, I've tried low bitrates (in CBR and VBR), low FPS, and adjusting GOP and i-frame counts. All the while, opening the feed in VLC on a computer and running it side by side shows zero distortion on the same feeds. I believe the issues is isolated to the raspberry pi and most likely omxplayer. The problem is, as far as I know, omxplayer doesn't have a settings system but rather accepts command line switches / modifiers and I don't know how to experiment with omxplayer and have Screenly OSE involved, because I don't know how it calls omxplayer and if its call can be modified to include switches / modifiers I want to trial.

Reproduction Steps

The distortion isn't always present. The only instance where I feel like it can be replicated with 90% probability of occurring is during the first ~5s of when the asset starts to play / stream. After that it comes and goes. I can't say for sure, but it seems to be triggers with movement / changes in the video. I.E., if the surveillance feed isn't seeing anything moving on the screen and the feed is static / more like a still image the distortion seems to be less likely to corrupt the feed.

Environment

I am running Screenly OSE Sprint 8 via the provided custom image on several Raspberry Pi 3 B+ SBCs.

[vpetersson]

@halfspec Interesting observation. In short, the RTSP feed in Screenly OSE is very simple. It simply launches omxplayer as you correctly pointed out. You're also right about the fact that it doesn't take many arguments.

My gut feeling tels me that your best bet is to increase the GPU memory. You can do this by running raspi-config.

[halfspec]

@vpetersson

Thank you for the reply and the very good suggestion. I hadn't thought about increasing the GPU memory size.

Unfortunately, I took it all the way up to 800MB for the GPU and 224MB for the CPU and I still see the video distortion out of the two RTSP feeds I am using for testing with VLC player also referencing the feeds on another machine running as a control to make sure the feed is not the problem. No improvements that I can see :(

Related note. The Pi3 + Screenly set with GPU Memory = 900MB and CPU = 124MB = not a happy Pi. Never could get to the initial blue screenly spash screen. Just blacks out after the raspberry post screen.

I should mention that I have experimented with the Pi's connection to the network where the RTSP feeds are setup (its all on a local network) to see if it was a bandwidth issue. Wifi and 1Gbit ethernet show the same symptoms with no noticeable difference between the two. Currently I'm still hardwired on 1Gbit ethernet.

Latest - I have been able to sortof duplicate the issue with VLC player by cutting its stream buffer time down from 1000ms to 100ms. I start to see distortion / artifacts in the stream that have some similarities to the Pi and omxplayer. It appears omxplayer has buffer settings as well, allowing its audio and video fifo stack sizes to be adjusted:

https://www.raspberrypi.org/forums/viewtopic.php?t=84820

Is it possible to edit screenly's call to omxplayer for experimentation?

Thanks again for the help. I'm definitely open any other suggestions you or anyone else has.

Lane

[vpetersson]

@halfspec Strange. Yeah, so the only thing I can think of is just what you describe: tweaking the omxplayer arguments. I would probably recommend that you install a regular Raspbian device for testing, but if you want to do it in Screenly directly, it should be this line if I'm not mistaken.

Oh, and don't forget to reboot after changing the GPU settings.

[halfspec]

@vpetersson

You rock my friend! Thank you for pointing me in the right direction. I also appreciate the recommendation for scratch starting a SD with raspbian and omxplayer for testing. I had that on my to-do list anyway to try and build a omxplayer based display to stream multiple rtsp streams (security camera viewer) simultaneously.

I will be back with my findings.

Thanks again Lane

[halfspec]

@vpetersson

Per your reccomendation I installed a fresh copy of Rasbian Jesse (I know. It's old, but I had it on hand), ran update, and started streaming my rtsp streams via omxplayer. Bam! Immediately I noticed the same distortion :(

However, after an hour of so of experimenting with arguments I'm hopeful I've stumbled onto the solution in the form of the --avdict argument. At least it appears to be working for the last hour.

omxplayer --avdict rtsp_transport:tcp "rtsp stream url"

Explicitly setting the transport protocol seems to really be helping out my situation. Like I said, I've seen no distortion for the hour I've been watching the pi's output. I'm going to run it overnight for 12hrs and I'll report back.

Lane

[vpetersson]

@halfspec Good finding! Yes, we could make these options available as "advance options" as it wouldn't be too hard to implement.

[halfspec]

@vpetersson

I can confirm that the avdict argument has solved my issue using a base install of Rasbian Jesse + omxplayer and loading the rtsp feed from the command with with said argument. It's run over 72hrs now with multiple restarts, reboots, etc and it hasn't flinched during any time that I've actually had eyes on the screen.

I would be happy to test this argument in screenly by adding it as an argument in the viewer.py file, but my lack of python syntax knowledge is holding me back. I figure line 322 needs to look something like this:

player_kwargs = {'o': settings['audio_output'], 'avdict': 'rtsp_transport:tcp uri', '_bg': True, '_ok_code': [0, 124, 143]}

But I know uri browser url needs to be handled properly, and the above code is not functional.

If you could help me straighten out the syntax I would be happy to test and verify operation on my end.

Thank you again Lane

[vpetersson]

@halfspec

Sure, I think you need to change L322 from:

player_kwargs = {'o': settings['audio_output'], '_bg': True, '_ok_code': [0, 124, 143]}

to:

 player_kwargs = {'o': settings['audio_output'], '--avdict': 'rtsp_transport:tcp', '_bg': True, '_ok_code': [0, 124, 143]}

I haven't touched this in a while, so I could be wrong on the syntax.

[halfspec]

@vpetersson

Thank you for the help. Your snippit suggestion, like my previous attempts, caused screenly to have problems loading. It would go to a black screen after the IP address splash screen displayed. However, you were closer than me. It appears the arguments don't need the explicit "--" prefix in front of them in python. Modifying to this fixed the problem:

player_kwargs = {'o': settings['audio_output'], 'avdict': 'rtsp_transport:tcp', '_bg': True, '_ok_code': [0, 124, 143]}

I'm currently displaying my rtsp stream with zero distortion. I'll report back after another 12-24hrs to let you know if it's stable.

Thanks again Lane

[vpetersson]

Yeah I recall there was something about that but couldn't recall the details exactly. Yes, please report back and also if you can provide the exact details on the cameras (make/model etc) so that we can write content around that, it would be useful.

[halfspec]

@vpetersson

Well, I've still got some issues, but I'm 99% sure it's not with Screenly OSE or the raspberry pi. I've been testing by creating a slideshow that switches every 1 minute between a raspberry pi picture and video and a networked rstp feed. It seems that the 1 minute connect, disconnect, and repeat is killing my little rstp server box, and I'm having to play with it's watchdog and timed restarts to keep it happy. Still, that's on another problem front. I believe the defined rtsp_transport has fixed my issue with omxplayer, screenly, and my raspberry pi.

The two sources I was getting distortion from were: Fmuser FBE200-H.265-HLS HDMI to RTSP encoder Hikvision DS-2CD2132F-I IP Camera

However, I really don't think the sources were the problem. I personally think it was due to how my network is configured and that explicit instructions for how omxplayer is to transport rtsp streams is needed to keep it using TCP exclusively. This digital signage pi is hosted in a 300person manufacturing plant, zero of which are IT. Our IT designed and manages our network and other things offsite. Because of that, I have limited information regarding the specifics of our network. I do know it's based around cisco hardware, but I have almost zero knowledge of how it's setup.

I'm sorry I can't be of more help. I really do appreciate the generous support.

Lane

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[JannickLeismann]

I had the same issues using raspberry (3b+ and 4b) and omxplayer by adding the --avdict rtsp_transport:tcp flag the distortion disappeard.