SAT>IP protocol
SAT>IP specifies the communication protocol between SAT>IP servers which transform satellite signals to IP and SAT>IP clients which consume satellite content. - See more at: http://www.ses.com/satip#sthash.6wqsSwG3.dpuf
I see there is also on forum VLC as a SAT>IP server
but first to implement client...
Activity
It would be helpful to have a software SAT>IP server for developers without hardware. E.g. to turn a Raspberry PI plus USB DVB device into a SAT>IP server. (one might also write a server that turns MPEG2TS over HTTP into SAT>IP so one can test without any dedicated hardware. SAT>IP client attached to vtuner(I've also talked in other ticket about something similar to test/reproduce problematic mux)
SETUP rtsp://192.168.128.5/?src=1&fe=1&freq=12402&pol=v&msys=dvbs&sr=27500&fec=34&pids=0,16,50,104,166,1707 RTSP/1.0 CSeq: 1 Transport: RTP/AVP;multicast;port=5004-5005Problems with Playing Sat>IP Radio-Stream
Should there be new category in Local Network devices(along UPnP and SAP)? Most will see only 1 expensive server on network, but will DVBlast handle more tuners in same time to number of users? Or every instance will have own UPnP/DLNA server?
Replying to [comment:3 Melis]:
Meh, the parts with RTSP make a weird and incompatible variant of the IETF RFC2326 specification. It does not use DESCRIBE, forbids multiple Transport specifications in SETUP, expects non-encoded equality sign in URI path, uses OPTIONS for session refresh, and adds the Session hereby to it. The latter misuse of OPTIONS violates RFC2326.
Anyway, it won't work with the normal RTSP handler, due to lack of DESCRIBE support. Another MRL scheme would be required. The HTTP transport might work fine out of the box though.
It would be helpful to have a software SAT>IP server for developers without hardware. E.g. to turn a Raspberry PI plus USB DVB device into a SAT>IP server. (one might also write a server that turns MPEG2TS over HTTP into SAT>IP so one can test without any dedicated hardware.
Well maybe but I understood this bug was about VLC client side, not server side. There is really not that much in common between the client and server side of the involved protocols here.
Should there be new category in Local Network devices(along UPnP and SAP)?
If the advertisement and discovery mechanism is compatible with UPnP A/V, then the server should show up already under UPnP (not to say that it will work though). If not, then indeed a new service discovery is needed. I am not familiar with UPnP and DLNA, so I don't actually know which way it goes.
Most will see only 1 expensive server on network, but will DVBlast handle more tuners in same time to number of users? Or every instance will have own UPnP/DLNA server?
You can only have one server per IP address. So if a box has multiple frontends, they will be multiplexed as one server still - unless a separate IP address is assigned for each frontend.
Discovery is compatible with UPnP.
So I suggest https://trac.videolan.org/vlc/attachment/ticket/11929/satip_discovery_patch.diff patch to discover SAT>IP servers and have access to the m3u list.
assigned to @fkuehne
added Component::Services discovery label
changed milestone to %3.0.0
commit b64e8e78 Author: Felix Paul Kühne fkuehne@videolan.org Date: Wed Oct 14 17:10:17 2015 +0200
UPnP discovery: add support for SAT>IP servers (closes [#11929](https://code.videolan.org/videolan/vlc/-/issues/11929), closes [#15540](https://code.videolan.org/videolan/vlc/-/issues/15540)) Some servers don't provide a playlist of their channels, so we need to download the list for the chosen satellite from the web and process it accordinglyadded Status::fixed label
changed milestone to %3.0 FF
