UDP stream receive (failed to add asset)

Anthias
1

Could someone help me to load a UDP stream (for example udp: //127.0.0.1: 9999) in the playlist so that it plays as an infinite asset?
When trying to load it I receive the following error “Server Error: Invalid URL. Failed to add asset.” although we know that omxplayer (the player used for RTSP & RTMP) supports it.
Thanks in advance!

2

You would have to implement something like this:
https://pypi.org/project/pyeasysocket/

Onto the ./screenly/lib/utils.py file

somewhere in this function:

def validate_url(string):
checker = urlparse(string)
    return bool(checker.scheme in ('http', 'https', 'rtsp', 'rtmp') and checker.netloc)
1 Like
3

Thanks for the contribution, next I leave a block of text to modify.
So far it is working properly.

   def url_fails(url):
    """
    If it is streaming
    """
    if urlparse(url).scheme in ('rtsp', 'rtmp', 'udp'):
        if arch in ('armv6l', 'armv7l'):
            run_omxplayer = omxplayer(url, info=True, _err_to_out=True, _ok_code=[0, 1])
            for line in run_omxplayer.split('\n'):
                if 'Input #0' in line:
                    return False
            return True
        else:
            run_mplayer = mplayer('-identify', '-frames', '0', '-nosound', url)
            for line in run_mplayer.split('\n'):
                if 'Clip info:' in line:
                    return False
            return True

    """
    Try HEAD and GET for URL availability check.
    """
4

Glad that fixed it.
@vpetersson, should we add UDP as part of the url_fails function? just as a way to cover the bases for any potential streaming server being used as asset?

5

Hmm. I’m not sure. RTSP and RTMP are UPD based protocols. We can’t accept anything UDP, just like we can’t accept anything TCP.

I’m rather curious about this particular situation. @leonidas300, what is the actual underlying feed here? Video streams are usually either RTSP or RTPM, thus my gut feeling tells me that it would equally well have worked by simply doing rtsp://127.0.0.1:9999 instead.

I bet that if we run ffprobe udp://127.0.0.1:9999 it will return either a RTSP or RTMP feed.

6

Hello people!
I tell you that you are in a small misconception.
Both RTMP and RTSP are TCP-based transport protocols.
I don’t understand what you mean by the following “We can’t accept anything UDP, just like we can’t accept anything TCP.”

Particularly the query arises from a need to transmit an SRT video streaming within an industrial plant which since SCREENLY uses for “omxplayer -o hdmi” for visualization. We need to decode it previously via srt-live-transmit srt: //: 8000 udp: //127.0.0.1: 9999

We still can’t get that when the SRT source “falls” the playlist continues.
When we succeed, we will publish the full fork in this feed, or if you want to join this fork, let me know!

7

Both RTMP and RTSP are TCP-based transport protocols.

Actually, this is not entirely true for RTSP at least. I had to look it up. According to RFC 2326, it’s both. TCP appears be used for the control commands, but either TCP or UDP can be used for the streaming.

I don’t understand what you mean by the following “We can’t accept anything UDP, just like we can’t accept anything TCP.”

Well, we need to know how to route it. The routing needs to be done on OSI Layer 7 (Application Layer). That way we know that URLs starting with https:// are web assets, and rtsp:// are streaming assets and can route them subsequently. If we just have a tcp://, we have no idea if that’s a video or web asset. The workaround might work for a particular use case, but wouldn’t work for the wider audience.

I’m not too familiar with streaming protocols, but if you just need to add support for srt:// to Screenly OSE, that would be straight forward. The viewer will then pass that on to omxplayer, which in turn might apply some logic and stream it from some other port.

1 Like
8

ideally, the best thing would be to incorporate support for SRT (client / rendezvouz)

9

If you can feed an srt:// feed to omxplayer directly (i.e. omxplayer srt://foobar:x) then we can support it easily.

10

unfortunately there is no direct support for SRT (secure reliable transport) in omxplayer.
Therefore we do it via srt-live-transmit.
srt-live-transmit srt: //: 8000 udp: //127.0.0.1: 9999
Then via omxplayer from the OSE frontend udp: //127.0.0.1: 9999
At the moment it is the loop that we find as a solution.
Clearly, a script could be written that when loading a slice SRT: // requests the stream via srt-live-transmit, but I don’t know how it would impact on screenly.
In case anyone on the team would like to give us a hand, that would be great.

11

@leonidas300
Maybe you can fork the current Screenly OSE, install srt-tools, edit the python lib/utils.py to add support for srt:// streams?