SAT>IP Server Implementation #597
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
perexg
force-pushed
the
master
branch
2 times, most recently
from
b30f05b
to
1bd1564
Compare
|
When can we start testing? Btw: Shouldn't it be possible to use another tvh instance as sat>ip client? |
perexg
force-pushed
the
satips
branch
3 times, most recently
from
af1fae1
to
e08624f
Compare
…dend specific server)
|
VLC does not support SAT>IP as far as I know: https://trac.videolan.org/vlc/ticket/11929 . SAT>IP RTSP usage is very limited and tvheadend supports only necessary parts, because HTTP streaming is better for most purposes. |
|
you are right, but all servers out there support vlc (Telestar Digibit R1, Octonet, Dvbviewer RS, minisatip, satpi) |
|
@9000h : OK, I added support for standard RTSP, too. It might be useful for some debugging purposes. |
|
I still missing something or have my setup not right, git pull is fresh. the client command |
|
Could you retry ? But EOVERFLOW errors are more serious. Users report them for this branch, trying to analyze, where's the cause. Unfortunately, my DVB-T tuner works ok. |
|
looks bit better now but still no stream |
|
@9000h : Fixed now.. It was a bit crazy problem. |
|
so, looks better now vlc did stream fta but decryption is not working up to now |
|
@9000h : Could you elaborate / show logs ? Can you stream a scrambled service through the standard HTTP streaming ? |
|
Yes non satip streams work fine with decryption |
|
first normal http stream, second same channel via rtsp satip |
|
The problem is that the mux is not matched (look to WARNING) and a new, temporary mux is created for the SAT>IP session. In this case the service is not descrambled, because there are not attached services to the temporary mux until the scan is complete. Does all parameters in the 538Mhz mux match to the satip rtsp request ? |
|
this is the request with the pmt pid in, and works with all satip server I can test |
|
Yep, but I don't know parameters of your 538Mhz mux defined in tvheadend.. It should be Annex A, freq 538000000 sym 6900000 mod QAM/256 fec NONE . EDIT: And this mux must be in the same network with the configured SAT>IP Source number. |
|
seem like the issue but why not using auto 2015-03-19 22:17:34.819 [WARNING] satips: 1/EF67D54D/0: extra parameter 'fec'='35' so there is no way |
|
the spec has no fec for dvb-c Example DVB-C Query: |
|
It seems another issue. The FEC is not matched. Could you retry with the latest fix now ? |
|
works |
|
I tried the SAT>IP server from Tvheadend with HDHomeRun device and it works fine, except Tvheadend reports transport errors and continuity errors at random when changing channels. Not when streaming, only when changing channels as far as I can see. Maybe someone else can check this configuration as well? (Tvheadend internal SAT>IP server + HDHomeRun) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This request gathers code for the SAT>IP Server implementation.
The implementation is almost complete and tested now except the PSI table rewrite routines (filtering, CA).
Implemented things:
Remaining things:
Notes:
The configuration is in the global config (number of tuners) and in the network settings (the source selection which is the integer identification of "position" for DVB-S (use 1 if you have only one DVB-S network), for DVB-T/C this value must be 1 to activate the SAT>IP Server for the given network).
TVH Server / Client uses own mechanism to pass the custom RTSP port (9983). The extra HTTP header is used when the XML description file is served "X-SATIP-RTSP-Port". Note that SAT>IP specification allow only standard RTSP port 554, so tvh must be run with root priviledges to bind to this port (the root priviledges are not used for standard operation when -u parameter is used - only for this initialization like other servers like apache or so do..). The maximum number for the sources (positions) is passed using "X-SATIP-Sources" header.
The internal MPEG-TS PID handling was updated to allow custom filtering for the SAT>IP server subscriptions, but the HTTP streaming benefits from this change too, because the mux play URL (http://host:9981/play/stream/mux/ or http://localhost:9981/stream/mux/) allow to pass the list of subscribed PIDs with the pids= argument now.
BTW: Hardware donations (SAT>IP clients) for testing will be appreciated. (Call to the hardware vendors.)
Last modification: 2015/Mar/17 16:53 CET