Right now the logic for dvb usage is the following:

* Get delivery system information (frequency, ....)
* configure dvbsrc to given frequency and set pid filter to PIDs known to be valid for everything. This includes the PAT
* tsparse receives data, eventually gets the PAT and posts that on the bus
  => Delay : Latency to receive PAT
* dvbbasebin identifies from the PAT which is the PMT for the selected program and adds the program PMT pid to the dvbsrc pid filter
  => Delay : Time for PMT PID data to start being filtered out
* tsparse receives data, eventually gets the PMT and posts that on the bus
  => Delay : Latency to receive PMT
* tsdemux also receives that PMT and creates the various source pads
* dvbbasebin identifies from the PMT which PIDs the program contains and adds those to the dvbsrc filter
  => Delay : Latency for PES pid to start being filtered out
* tsparse (and tsdemux) receives data for the various program streams, eventually starts receiving packets for the beginning of PES packets, starts aggregating them and pushes them out to be decoded.
  => Delay : Latency to get initial whole PES
* eventually decoders have enough data to start decoding and push out to display/render.
  => Delay : Latency to get enough data for decoders to start outputting data

(phew)

This ends up with a quite high latency between the moment we select a channel and the moment data starts getting displayed/rendered.

In order to cut that down drastically, there are a series of steps/tricks that could be undertaken. This assumes that the streams aren't scrambled, otherwise these tricks will not work.

1) Add support in mpegtbase (and therefore tsdemux/tsparse) to detect whether streams contains PES or PSI data. This is trivial/guaranteed to detect. Is a packet is marked PUSI and has a payload, then either the payload starts with 0x000001 and it's a PES stream, or else it's a PSI stream. The specifications are pretty clear on this.

2) Start accumulating PES data in tsdemux even for streams we are not sure are part of the selected program (i.e. we still haven't received the PMT, we do not know what type of PES data is contained within ,....). The logic stays entirely the same, except that instead of pushing out the data, we put it on a waiting queue.

3) The moment tsdemux finally gets the selected program PMT and it has created all the proper source pads, .... , we delete data from the streams we are not interested in (not part of the selected program) and we push out all the pending data. We also obviously stop collecting data from the PES streams that are not part of the selected program.

4) When dvbbasebin is started, instead of only selecting a subset of PID to filter initially (PAT + common DVB PID) ... it deactivates the filtering (Setting it to 8192, meaning we will get *all* streams).

5) The moment dvbbasebin receives from tsparse the PMT of the selected program (the service id is contained in the channels.conf), it sets the dvbsrc PID filtering to the proper selection of PID (PAT + common DVB PID + program PID + PCR PID, ...).


Advantages:
* Since we collect data from all PES right from the start, the decoders will have a much bigger chance of ending up having enough data to start decoding faster and rendering should happen the moment the demuxer adds its source pads (minus time taken to decode data).
* Latency is reduced to time it takes to get the selected program PMT.

Downsides:
* Increased initial cpu, memory and i/o usage. Might want to have a way to configure this behaviour for embedded devices.