Project

General

Profile

DVB-based origins inhibit expansion

Added by Robert Cameron almost 7 years ago

I'm not quite sure where to post this, but this category seemed the most appropriate.

I'm in the process of trying to add/create a CableCARD network and associated support types, but am running into several roadblocks based upon Tvheadend's heritage. It's quite obvious when looking at the sources that Tvheadend was primarily/originally developed for DVB inputs. While ATSC and similar broadcast types have been supported, the needs of these other broadcast types have shown up in the source as DVB derivatives.

Even while looking at the IPTV sources, or even the newer TS file types, the heritage for DVB is quite evident. Even attempting to subclass (for lack of a better term) the generic mpegts_network type necessitates bringing in DVB specific headers for what should be TS/PS/ES/PES only needs. Similarly, while trying to look at EPGGrabbers, especially for internal structures, the reliance on DVB is still evident.

I know that separating the generic MPEG-TS structures is mostly done, but the overall structures of network/mux/service still favor the DVB origins. As such, it makes extending TVH to include similar MPEG-TS networks (and their associated inputs), such as CableCARD, difficult as it introduces more points for error than necessary. While I have a rough skeleton of how such a network would work, it does include working around the DVB-specific bits of code inherent to Tvheadend's paradigm.

While this isn't necessarily a call for refactoring, such a result would not be remiss. TVH's documentation is lacking (XML/JSON HTTP, current HTSP ...), and as such, perhaps after 4.4, it's time to look at the project's structure. A more general look at networks, inputs, streams and subscriptions might help to make both configuration easier for end users, as well as making the platform easier for developers to contribute.


Replies (1)

RE: DVB-based origins inhibit expansion - Added by Mark Clarkstone almost 7 years ago

I think you might get more responses by creating this as an issue?

While this isn't necessarily a call for refactoring, such a result would not be remiss. TVH's documentation is lacking (XML/JSON HTTP, current HTSP ...), and as such, perhaps after 4.4, it's time to look at the project's structure. A more general look at networks, inputs, streams and subscriptions might help to make both configuration easier for end users, as well as making the platform easier for developers to contribute.

While I don't disagree with you, the problem is the lack of developers and time. This being an open project means anyone can contribute if they so wish. :) I'm not saying there are no developers at all, just the ones we do have are extremely busy. Thankfully more people do seem to be contributing as of late, which is extremely nice to see!

Don't feel that you can't contribute, doesn't matter how small :).

    (1-1/1)