Tvheadend

You should describe your goal.

Jaroslav Kysela wrote:

You should describe your goal.

I like to develop a new Input source reusing the code of IPTV and TSFILE. In fact all "src/input/mpegts/*" inputs share a lot of code. For example, the superclass "mpegts_input" defines the interface function "mi_update_pids()". But this function is only implemented by the sources (subclasses): hdhomerun, satipc, and linuxdvb. If the sources "iptv" or "tsfile" will have this function implemented, for example with a default superclass implementation, then will be more simple to reuse it. For example, the default implementation can be a software pid filtering.

I hope this explanation will be suficient.
Any comment?

This PID subscription is only useful for the hardware filtering. That's the reason why only hardware inputs have this implemented. For software only inputs, it's enough to send unmodified stream through mpegts_input_recv_packets() and the mpegts_input_process() function will do the rest of the PID filtering.

Jaroslav Kysela wrote:

This PID subscription is only useful for the hardware filtering. That's the reason why only hardware inputs have this implemented. For software only inputs, it's enough to send unmodified stream through mpegts_input_recv_packets() and the mpegts_input_process() function will do the rest of the PID filtering.

Hi,

Thank you for the clarification! However, the new input source that I like to develop it needs to know the pids used in the output. This it's mandatory as the input has more than one source. This is the real reason for request this. So, if the internal code currently can do the PID filtering; the only information that I need it's the list of current used pids.

Please, can you explain how the source (the subclass) can receive this information?

There's already mi_update_pids callback in the mpegts_input_t class.

Jaroslav Kysela wrote:

There's already mi_update_pids callback in the mpegts_input_t class.

OK. Thank you for the info. I'll test it. :)