[Bug 703884] New: dvb/tsdemux: Fast start variant

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=703884
  GStreamer | gst-plugins-bad | git

           Summary: dvb/tsdemux: Fast start variant
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: bilboed at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.