Feature #4784
open
SAT>IP: refactoring of IPTV inputs
Added by Mono Polimorph over 7 years ago. Updated over 6 years ago.
0%
Description
Hi Jaroslav,
I refactored the functionality of the SAT>IP server for IPTV inputs.
Until now you can only export regular IPTV inputs through the SAT>IP service. However, with this patch the support is enhanced to any MPEG-TS Input.
This change opens new scenarios. For example:
- You have a SAT>IP device that supports only DVB-S2 sources, but you like to access to DVB-T signals too. Then you can scan for your DVB-T muxes and 'remap' them to some DVB-S frequencies.
- You want to mix two different networks over one. For example, you have a DVB-S2 SAT>IP server and one DVB-C card. Then you can 'remap' the DVB-C muxes over free DVB-S frequencies and configure the SAT>IP in TVH. So, any SAT>IP client that connects to the TVH SAT>IP server can see the two networks over one.
And so on. And if you dreamed with TS input files exported over SAT>IP, or exporting recordings... then you will can do it in the future using this patch and some additional work.
I hope you agree with this change. Please, comment about it! ;)
Just one advice: This patch doesn’t translate any old configuration of IPTV SAT>IP frequencies. It’s required to set the values again. (!)
Regards.
Files
| SAT-IP-Server-remap-for-all-MPEGTS-inputs.diff (7.41 KB) SAT-IP-Server-remap-for-all-MPEGTS-inputs.diff | Mono Polimorph, 2017-12-11 21:57 | ||
| SAT-IP-Server-remap-for-all-MPEGTS-inputs-v2.diff (7.58 KB) SAT-IP-Server-remap-for-all-MPEGTS-inputs-v2.diff | Mono Polimorph, 2017-12-12 18:29 | ||
| SAT-IP-Server-remap-for-all-MPEGTS-inputs-v3.diff (7.65 KB) SAT-IP-Server-remap-for-all-MPEGTS-inputs-v3.diff | version 3 | Mono Polimorph, 2018-01-25 16:39 | |
| SAT-IP-Server-remap-for-all-MPEGTS-inputs-v4.diff (7.38 KB) SAT-IP-Server-remap-for-all-MPEGTS-inputs-v4.diff | Mono Polimorph, 2018-02-01 12:43 |
Updated by Mono Polimorph over 7 years ago
- File SAT-IP-Server-remap-for-all-MPEGTS-inputs-v2.diff SAT-IP-Server-remap-for-all-MPEGTS-inputs-v2.diff added
Hi Jaroslav,
Here an updated version of the patch. The previous one lacks support for "file-input". Now it works with any TS file configured as a device input. So, you can play it using the SAT>IP protocol! :D
In addition now it warns when an unsupported inputs is requested and prints the class type.
Please, comment about this patch! I like to see it committed soon!
One question: When using the "file-input" (enabled by the command line with '--tsfile_tuners' and '--tsfile') I have a problem... each time the TVH starts a new mux is created for each file. So the SAT>IP frequency values are lost when the TVH is closed. So, I need to set them for using it with the SAT>IP protocol. Any change for static storing of this muxes?
Regards!
Updated by Mono Polimorph over 7 years ago
Hi Jaroslav,
The cause because the "file-input" configuration isn't saved it's described in #4789.
I comment here only for reference.
Regards.
Updated by Mono Polimorph over 7 years ago
Hi Jaroslav,
You agree with this patch?
Regards!
Updated by Mono Polimorph over 7 years ago
Hi Jaroslav,
This patch is very interesting! Please, review it.
It enables the option for remapping different delivery systems. For example, from DVB-C to DVB-S.
If you're unconfortable with something, please comment about it.
I like to incorporate the option for a full remapping in the SAT>IP output, as a lot of clients only handle DVB-S.
Regards!
Updated by Jaroslav Kysela over 7 years ago
To be honest, I'd like to see a new tab with this mapping instead this. It will allow us also to map the mux multiple times to the SAT>IP resource space.
Updated by Mono Polimorph over 7 years ago
Jaroslav Kysela wrote:
To be honest, I'd like to see a new tab with this mapping instead this. It will allow us also to map the mux multiple times to the SAT>IP resource space.
Hi,
Thank you for comment it!
Regarding, your suggestion: it's very difficult for me to "edit" the IU. If you provide this part then I can develop the internal part. However, this patch only "extends" the current functionality. So it can be an intermidiate function previous to your wises.
Please, can you describe with more detail your vision?
Regards.
Updated by Mono Polimorph over 7 years ago
Mono Polimorph wrote:
Jaroslav Kysela wrote:
To be honest, I'd like to see a new tab with this mapping instead this. It will allow us also to map the mux multiple times to the SAT>IP resource space.
Please, can you describe with more detail your vision?
Hi Jaroslav,
I'm waiting for your response. I'm very interested in this functionality (replace DVB-C/T with DVB-S frequencies when exporting over the SAT>IP protocol). And now I'm ussing my patch with satisfaction.
However, if you disagree with my approach, please point me in the right direction.
Thank you!
Updated by Mono Polimorph over 7 years ago
Hi Jaroslav,
You don't like to comment about this patch?
Updated by Mono Polimorph over 7 years ago
Hi Jaroslav,
I'm waiting for your feedback!
At this point I have two options for improve this patch:
Option 1: Add a simple "import" of old IPTV configuration (going from "iptv_satip_dvb?_freq" to "remap_satip_dvb?_freq"). This will provide a non-intrusive patch for current IPTV, and for the rest it will provide the option of SAT>IP exports for all MPEG-TS inputs.
Option 2: Add a new tab for MUX mappings to SAT>IP frequencies.
If you prefer the option 2, please comment about it as I need some help to start with it.
Thank you!
Updated by Mono Polimorph about 7 years ago
Jaroslav Kysela wrote:
To be honest, I'd like to see a new tab with this mapping instead this. It will allow us also to map the mux multiple times to the SAT>IP resource space.
Hi Jaroslav,
To be honest, I'm using this patch for a lot of time. And I feel you prefer a new method for mapping SAT>IP outputs to configured inputs. Furthermore, I agree that it's the best solution.
However, until you can implement this new function, I suggest to apply this patch. I’m sure other users will like to use the options provided by this patch: remap DVB-C/T inputs to DVB-S; remap complex satellite inputs to plain DVB-C inputs, etc.
The only remaining point to make this patch transparent for users, it’s the migration of the current configuration to the new format. As the SAT>IP remapped frequencies are applied to MPEG-TS inputs, instead of IPTV inputs, it’s required some migration. I analyzed the code of the “config.c” related to “config_migrate_v*()” functions. However, I feel this it’s only for convert config data over official major releases. So, please can you help me to complete this patch?
Thank you for supporting this great project!
Regards.
Updated by Mono Polimorph about 7 years ago
- File SAT-IP-Server-remap-for-all-MPEGTS-inputs-v3.diff SAT-IP-Server-remap-for-all-MPEGTS-inputs-v3.diff added
Hi Jaroslav,
Here a new version of my patch!
I think you’ll be finally comfortable with this new version. If not, please comment about it. (!)
What’s new? Now the old values from the IPTV configuration are “migrated”.
However, the migration it’s a simple mapping of the configuration values with the old names. And it has some benefits and one drawback. The good thing is that the users who update do not lost any data. Even more, if they return to an old version of TVH the old configuration for all IPTV sources will continue intact. Furthermore, if they configure any IPTV source with a SAT>IP frequency, and after they return to an old version (or copy the configuration), the configuration continues to be valid. The only drawback it’s that the value is saved two times for IPTV inputs (this it’s only true after new or update). I feel this penalty is insignificant compared with the benefits. As you can see in the patch, this change can be possible because the “iptv_mux_class” is a subclass of “mpegts_mux_class”. And the new values of the SAT>IP frequencies are now in this superclass. Note taht I prefer to maintain different names for the config values (“iptv_satip_dvb*_freq” and “remap_satip_dvb*_freq”). If you like, you can use the old names, and then the config values will be only saved one time. So no drawback in this case (except that the name “iptv_” in the config will not be realistic).
Note also that the patch does the correct search and remapping of the sources to the SAT>IP server. It distinguish between DVB sources, IPTV sources and generic MPEG-TS sources. It is fully tested and works perfectly with any of the compatible inputs.
So, with this patch you can do:
- Re-export your HDHomeRuns DVB-T/C tuners as SAT>IP sources. :)
- Remap your DVB-C or DVB-T tunes as DVB-S signals (or vice versa). :D
- Map IPTV sources as SAT>IP (this isn’t new!). :P
- Export TSFILES as SAT>IP sources for testing. ;)
And any new MPEG-TS input will can be exported too using the SAT>IP protocol.
So, I hope this time you’ll agree to commit this patch. (/)
Regards!
Updated by Mono Polimorph about 7 years ago
- File SAT-IP-Server-remap-for-all-MPEGTS-inputs-v4.diff SAT-IP-Server-remap-for-all-MPEGTS-inputs-v4.diff added
Hi Jaroslav,
Thinking more on the wasted space in the configuration, I refactored the patch. Now it's more simple... the only drawback it's that the parameter in the config continues to start the name with "iptv_*". In any other aspect this patch is "perfect" (in the sense that this accomplish the objective).
Please, until you reformulate the UI commented in http://www.tvheadend.org/issues/4784#note-5 add this patch to the mainstream.
Regards! :)
Updated by Mono Polimorph about 7 years ago
Hi Jaroslav,
No comment for around two weeks? :(
The version 4 of the patch works like a charm!
Updated by Mono Polimorph about 7 years ago
Hi Jaroslav,
I don't know enough about the source of the TVH to create a new tab with these mappings. But this patch improves a lot the use of the SAT>IP server. Futhermore, I dedicated a lot of time to resolve then problems and create a fine solution. And it's tested for weeks without problems. It works like charm!
So, please, can you tell what you think?
Thank you for your good work! :) :)
Updated by Mark Clarkstone about 7 years ago
Mono Polimorph wrote:
... snip ...
I know you're itching to get your patches into tvh, and they're very welcome, but please remember patches via redmine have to be done manually and can be easily forgotten about!
Are you able to access another git service or is it just github you can't access?
Updated by Mono Polimorph about 7 years ago
Mark Clarkstone wrote:
Mono Polimorph wrote:
... snip ...
I know you're itching to get your patches into tvh, and they're very welcome, but please remember patches via redmine have to be done manually and can be easily forgotten about!
Are you able to access another git service or is it just github you can't access?
Hi Mark,
Thank you for your response. Thanks a lot!
I understand the "interference" in the development work that can occasionally this "manual"request. I don't like to be a stumble!
Futhermore, I can wait until Jaroslav (or another developer) can review the patch. However, I think it can be possible to write some "comment" here, even if it's a simple: "pending to check" or "seems right, pending".
In any case: I can't access any git service. I have a several limitations to access them. And I can't change this. The only solution I see it's sending the patch to another person. So, what do you prefer, to post here, or to send it a colleague and let him generate the PR?
Regards! :)
Updated by Pablo R. about 7 years ago
I can submit your patches on Git if you want... Tell me.
Updated by Mono Polimorph about 7 years ago
Pablo Rodríguez wrote:
I can submit your patches on Git if you want... Tell me.
Thanxs a lot, Pablo! :)
As the patches are published here, I put the list of pending patches here:
- http://www.tvheadend.org/issues/4784 (get version 4).
- http://www.tvheadend.org/issues/4938
- http://www.tvheadend.org/issues/4934
You only need to clone the git-hub and apply one patch for each PR.
Regards.
Updated by Pablo R. about 7 years ago
Mono Polimorph wrote:
Pablo Rodríguez wrote:
I can submit your patches on Git if you want... Tell me.
Thanxs a lot, Pablo! :)
As the patches are published here, I put the list of pending patches here:
- http://www.tvheadend.org/issues/4784 (get version 4).
- http://www.tvheadend.org/issues/4938
- http://www.tvheadend.org/issues/4934
You only need to clone the git-hub and apply one patch for each PR.
Regards.
Done!
Updated by Mono Polimorph almost 7 years ago
Pablo R. wrote:
Mono Polimorph wrote:
Pablo Rodríguez wrote:
Done!
Thank you, Pablo!
Any idea why this patch isn't already merged?
I'm using it for a lot of time. Zero problems! Other friends are testing it too! However, for some platforms it's useful to use official/regular releases. So the patch needs to be accepted.
Any commet?
Please! ;)
Updated by Mono Polimorph almost 7 years ago
Hi,
A month after still waiting... no comments?
Updated by Flole Systems almost 7 years ago
Hi,
I've also been testing this, it works great. Can we get this merged please?
Updated by Mark Clarkstone almost 7 years ago
Flole Systems wrote:
Hi,
I've also been testing this, it works great. Can we get this merged please?
When perexg comes back off a well deserved break I'm sure he will :).
Updated by Mono Polimorph over 6 years ago
When perexg comes back off a well deserved break I'm sure he will :).
Looks like he's back now. Good!
I hope he reconsider to accept, or at last to modify and improve, this patch.
Regards.
Updated by Jaroslav Kysela over 6 years ago
I don't like to have three new rows for SAT>IP in each mux. After some more thinking, we can do this a bit differently without new tab / massive UI changes. There might be only one variable labeled for example 'SAT>IP reshare name' which will point to a configuration which will describe the SAT>IP frequencies (and positions for DVB-S). Something like this - configuration file data/conf/satip-muxes:
{
"mux1": [
{ "sys":"dvbc", "freq": 658000000 },
{ "sys":"dvbt", "freq": 312000000 },
{ "sys":"dvbs", "pos": 1, "freq": 12610500 },
{ "sys":"dvbs", "pos": 3, "freq": 11797000 }
],
"mux2": {
{ "sys":"dvbt", "freq": 372000000 }
}
}
Updated by Mono Polimorph over 6 years ago
Jaroslav Kysela wrote:
I don't like to have three new rows for SAT>IP in each mux. After some more thinking, we can do this a bit differently without new tab / massive UI changes. There might be only one variable labeled for example 'SAT>IP reshare name' which will point to a configuration which will describe the SAT>IP frequencies (and positions for DVB-S). Something like this - configuration file data/conf/satip-muxes:
[...]
First: Thank you to comment about this issue! :)
Regarding your suggestion: I feel it will be a lot more powerful. I hope you can implement it soon. Please let me know if there's anything I can do to help.
Regards.
Updated by Jaroslav Kysela over 6 years ago
No ETA from me - I don't need this. You may give a try to implement this yourself.
Updated by Mono Polimorph over 6 years ago
Jaroslav Kysela wrote:
No ETA from me - I don't need this. You may give a try to implement this yourself.
Hi Jaroslav,
I'm sad to hear that!
I use this function a lot, and other users request it... And I feel it isn't easy to me to do it.
Please, can you do some coding to start? I don't know how to generate the configuration part (data/conf/satip-muxes).
Updated by Jaroslav Kysela over 6 years ago
It's JSON format. You should write the configuration file yourself. Just place it to the configuration directory like files 'config' or 'epgdb.v3'. An example for parsing is in src/descrambler/descrambler.c - descrambler_init() and descrambler_load_hints().
Updated by Mono Polimorph over 6 years ago
Jaroslav Kysela wrote:
It's JSON format. You should write the configuration file yourself. Just place it to the configuration directory like files 'config' or 'epgdb.v3'. An example for parsing is in src/descrambler/descrambler.c - descrambler_init() and descrambler_load_hints().
Thank you for the tip!
I'll try. ;)