Project

General

Profile

Feature #4930

MPEG-TS source: Add pid control support

Added by Mono Polimorph over 6 years ago. Updated over 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
General
Target version:
-
Start date:
2018-02-09
Due date:
% Done:

0%

Estimated time:

Description

Hi,

It will be great if the generic MPEG-TS source will have support for a pid list control. At time, only the SAT>IP source has this capability. However, if the superclass will have the functions for setting/controlling pid filtering, then it will be more simple to create other derivates of the MPEG-TS input source with this functionallity.

You agree to incomporate this function?
I feel it can be easy to move some code from the SAT>IP client class to the MPEG-TS source class and create empty functions in the other subclasses without this control.

What you think?

History

#1

Updated by Jaroslav Kysela over 6 years ago

You should describe your goal.

#2

Updated by Mono Polimorph over 6 years ago

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?

#3

Updated by Jaroslav Kysela over 6 years ago

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.

#4

Updated by Mono Polimorph over 6 years ago

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?

#5

Updated by Jaroslav Kysela over 6 years ago

There's already mi_update_pids callback in the mpegts_input_t class.

#6

Updated by Mono Polimorph over 6 years ago

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. :)

Also available in: Atom PDF