Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make inputstream configurable #177

Closed
dagwieers opened this issue Sep 19, 2019 · 5 comments
Closed

Make inputstream configurable #177

dagwieers opened this issue Sep 19, 2019 · 5 comments
Labels
Milestone

Comments

@dagwieers
Copy link
Collaborator

dagwieers commented Sep 19, 2019

Currently we have a hard-coded mapping between input-format and inputstream plugin. And this makes sense because there currently are only 2 inputstream plugins (adaptive and rtmp) however in the future it is likely alternative inputstream implementations exists.

So rather than make this hard-coded, we could allow the user to select what inputstream plugin is used for what input-format. This is possible using:

<setting label="32111" type="addon" id="is_mpd" default="inputstream.adaptive" addontype="inputstream"  multiselect="false"/>
<setting label="32112" type="addon" id="is_hls" default="inputstream.adaptive" addontype="inputstream"  multiselect="false"/>
<setting label="32113" type="addon" id="is_ism" default="inputstream.adaptive" addontype="inputstream"  multiselect="false"/>
<setting label="32114" type="addon" id="is_rtmp" default="inputstream.rtmp" addontype="inputstream"  multiselect="false"/>

Even if we don't want to make this configurable (yet), we could add this as invisible settings until it becomes useful.

This would make config.py a little less relevant.

@dagwieers dagwieers added this to the Future milestone Sep 19, 2019
@emilsvennesson
Copy link
Owner

I'm not a fan of this idea. Right now, there's really no reason to allow the user to choose which add-on to use because there is only one option that will work.

This would make sense to me if there were multiple add-ons supporting one protocol, which may happen in the future, but I don't see the benefit of this right now.

@emilsvennesson
Copy link
Owner

I just saw your edit about making it a hidden setting. That's completely fine with me. :-)

@dagwieers
Copy link
Collaborator Author

dagwieers commented Sep 19, 2019

I just saw your edit about making it a hidden setting. That's completely fine with me. :-)

It would indeed be moving this out of config.py into settings.xml. The goal being that we get rid of config.py (as a config file) into e.g. data.py (a datastore with fixed mappings) over time.

Relates to #94

@emilsvennesson
Copy link
Owner

@dagwieers Sounds good to me. config.py has always been intended as an internal dictionary and not for users to edit themselves. The naming of the file was pretty stupidly thought out... 😬️

@dagwieers dagwieers modified the milestones: Future, Revisit Nov 7, 2019
@dagwieers
Copy link
Collaborator Author

Revisit later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants