Bug #4341
open
SAT>IP server: Add support for standard SAT>IP HTTP requests for MPEG-TS streams
Added by Evgenii Metelev almost 8 years ago.
Updated almost 8 years ago.
Estimated time:
(Total: 0:00 h)
Found in version:
4.2.1-7~g4d4bf14
Description
Hello everyone! Trying to make this scenario: run the tvheadend,as input to mux is some test.ts file( file:///test.ts). In test file we have mix of streams(channels) from Astra satellite. Tvheadend is set up as sat-ip server. From "services/channels" tab he sees channels from ts file. In networks settings "SAT>IP source number" set to 1. So i want to get from the output stream of some particular channel played by either of vlc, sat-ip player or else. I try to open in vlc:
rtsp://172.31.14.154:554/?src=1&freq=12604&msys=dvbs&plts=off&fec=56&pol=h&ro=0.35&sr=22000&mtype=qpsk&pids=0
In logs i see
"[WARNING] satips: 0/C6F7315E/7: unable to create mux DVB-S freq 12604000 H sym 22000000 fec 5/6 mod QPSK roff 35 is_id -1 pls_mode ROOT pls_code 0"
Http also does not play.
The question is is it possible such a scenario? What am i doing wrong? How to play stream from sat-ip tvheadend server?
tvheadend: version 4.2.1-7~g4d4bf14
Set also 'SAT>IP DVB-T frequency (Hz)' for the IPTV mux and enable DVB-T SAT>IP server. Configure the client to use DVB-T SAT>IP request with the given frequency. The muxes are 'virtual'.
Also, note that pids=0 does not contain a valid mpeg-ts stream for vlc with audio and video. It's just PAT table. Try to use 'pids=all'.
Thank you some much, now it works good for rtsp with!
But can we play that by http? I do in vlc
http://172.31.14.154:9981/?src=1&freq=12604&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=22000&fec=56&pids=0,17,18,5601,5602,5600,5604
but nothings happens in tvheadend logs, and vlc says:
core input error: open of `extjs.html?src=1&freq=12604&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=22000&fec=56&pids=0%2C17%2C18%2C5601%2C5602%2C5600%2C5604' failed
pids are correct. Maybe
TVH abstracts the HTTP streaming, the SAT>IP like HTTP requests are not supported (I've not found an use for it). TVH can generate own playlists with the universal HTTP streaming - see build-in Help - Appendix 1.
Jaroslav Kysela wrote:
TVH abstracts the HTTP streaming, the SAT>IP like HTTP requests are not supported (I've not found an use for it). TVH can generate own playlists with the universal HTTP streaming - see build-in Help - Appendix 1.
I ask because SAT>IP specification says "that SAT>IP Media servers shall also be controllable via HTTP based requests."
"Example http get message:
http://192.168.128.1/?src=1&fe=1&freq=12402&pol=v&msys=dvbs&mtype=qpsk&sr=27500&fec=34&pids
=0,16,50,104,166,1707"
Maybe in the near future plan to support sat>ip http requests?
"shall" is not "must"
Again, show me the client which uses this transfer method.
this is a TV software that plan in near future such requests, alongside with rtsp.
If you like to test only this transfer method, you may use minisatip SAT>IP server as your server. It supports HTTP requests. minisatip can eventually connect to the TVH's SAT>IP server as source (it has build-in SAT>IP client, too).
The RTSP protocol can use embedded data inside the RTSP TCP session. See https://www.ietf.org/rfc/rfc2326.txt : 10.12 Embedded (Interleaved) Binary Data . TVH supports this RTSP transfer method. The benefit is that the client can dynamically update the subscription params (pids, retune) and get the signal state (RTCP) like for standard RTSP/RTP/UDP transfers. Unfortunately, it's not part of the SAT>IP spec.
- Subject changed from SAT-IP: Mpeg transport stream as input to tvheadend sat-ip server and play that stream via sat-ip protocol to SAT>IP server: Add support for standard SAT>IP HTTP requests for MPEG-TS streams
- Target version set to 999
Great!
I like to see this implemented... in version 4.6
Just one suggestion: As minisatip does, please, support multiple requests when streaming. This isn't compilant with the original HTTP (nor the SAT>IP specification), but is easy to implement. The idea is process additional pid changes (new HTTP requests) when streaming over the HTTP protocol.
The problem is that infinite streaming over HTTP doesn't support to receive requests from the user when sending data... as the sever needs to send the HTTP header response will sending the stream. My suggestion is foget to send the response, or send it interlaved as an encapsulated MPEG-TS packet with fake pids... Then the client will continue receiving the stream without problems.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by