After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 703884 - dvb/tsdemux: Fast start variant
dvb/tsdemux: Fast start variant
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 715147
 
 
Reported: 2013-07-09 16:24 UTC by Edward Hervey
Modified: 2018-05-04 11:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Edward Hervey 2013-07-09 16:24:30 UTC
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.
Comment 1 Edward Hervey 2013-12-21 06:12:56 UTC
Note that this also means we can parse the PMT before the PAT (we know which streams are SI/PSI much earlier).

Not that we would expose the program at that time (we don't know yet if it's the selected one), but we could do some operations ahead of time. And it might help bug #715147
Comment 2 Edward Hervey 2013-12-21 06:22:05 UTC
Another dvbbasebin optimization to do (which maybe should go in a different bug report) is to store the observed stream-PID for each program in a configuration file. That way we don't have to wait for the PMT to know which PID we should activate.

Ex:
PROGRAM_1:<pmt_pid>:<program1_pes_pid1>,<program1_pes_pid2>,....

That will allow us to start with a reduced number of PID (filtering activated on the frontend). The probability the PMT PID and program stream PID changed over time is very low. If they do change, we can still go back to the old logic (at the expense of latency).

Obviously a system-wide daemon would help with that ... but in 10+ years of dvb-linux nobody has agreed on a common solution :(
Comment 3 Edward Hervey 2018-05-04 11:44:52 UTC
Would be great but I don't intend on working on it. Closing.