docs/design/part-sparsestreams.txt

   1 DRAFT Sparse Streams
   2 --------------------
   3
   4 Introduction
   5 ~~~~~~~~~~~~
   6
   7 In 0.8, there was some support for Sparse Streams through the use of
   8 FILLER events. These were used to mark gaps between buffers so that downstream
   9 elements could know not to expect any more data for that gap.
  10
  11 In 0.10, segment information conveyed through NEWSEGMENT events can be used
  12 for the same purpose.
  13
  14 Use cases
  15 ~~~~~~~~~
  16
  17 1) Sub-title streams
  18   Sub-title information from muxed formats such as Matroska or MPEG consist of
  19   irregular buffers spaced far apart compared to the other streams
  20   (audio and video). Since these usually only appear when someone speaks or
  21   some other action in the video/audio needs describing, they can be anywhere
  22   from 1-2 seconds to several minutes apart.
  23
  24   Downstream elements that want to mix sub-titles and video (and muxers)
  25   have no way of knowing whether to process a video packet or wait a moment
  26   for a corresponding sub-title to be delivered on another pad.
  27
  28 2) Still frame/menu support
  29   In DVDs (and other formats), there are still-frame regions where the current
  30   video frame should be retained and no audio played for a period. In DVD,
  31   these are described either as a fixed duration, or infinite duration still
  32   frame.
  33
  34 3) Avoiding processing silence from audio generators
  35   Imagine a source that from time to time produces empty buffers (silence
  36   or blank images). If the pipeline has many elements next, it is better to
  37   optimise the obsolete data processing in this case. Examples for such sources
  38   are sound-generators (simsyn in gst-buzztard) or a source in a voip
  39   application that uses noise-gating (to save bandwith).
  40
  41 Details
  42 ~~~~~~~
  43
  44 1) Sub-title streams
  45   The main requirement here is to avoid stalling the pipeline between sub-title
  46   packets, and is effectively updating the minimum-timestamp for that stream.
  47
  48   A demuxer can do this by sending an 'update' NEWSEGMENT with a new start time
  49   to the subtitle pad. For example, every time the SCR in MPEG data
  50   advances more than 0.5 seconds, the MPEG demuxer can issue a NEWSEGMENT with
  51    (update=TRUE, start=SCR ). Downstream elements can then be aware not to
  52    expect any data older than the new start time.
  53
  54   The same holds true for any element that knows the current position in the
  55   stream - once the element knows that there is no more data to be presented
  56   until time 'n' it can advance the start time of the current segment to 'n'.
  57
  58   This technique can also be used, for example, to represent a stream of
  59   MIDI events spaced to a clock period. When there is no event present for
  60   a clock time, a NEWSEGMENT update can be sent in its place.
  61
  62 2) Still frame/menu support
  63   Still frames in DVD menus are not the same, in that they do not introduce
  64   a gap in the timestamps of the data. Instead, they represent a pause in the
  65   presentation of a stream. Correctly performing the wait requires some
  66   synchronisation with downstream elements.
  67
  68   In this scenario, an upstream element that wants to execute a still frame
  69   performs the following steps:
  70
  71     * Send all data before the still frame wait
  72     * Send a DRAIN event to ensure that all data has been played downstream.
  73     * wait on the clock for the required duration, possibly interrupting
  74       if necessary due to an intervening activity (such as a user navigation)
  75     * FLUSH the pipeline using a normal flush sequence (FLUSH_START,
  76       chain-lock, FLUSH_STOP)
  77     * Send a NEWSEGMENT to restart playback with the next timestamp in the
  78       stream.
  79
  80   The upstream element performing the wait must only do so when in the PLAYING
  81   state. During PAUSED, the clock will not be running, and may not even have
  82   been distributed to the element yet.
  83
  84   DRAIN is a new event that will block on a src pad until all data downstream
  85   has been played out.
  86
  87   Flushing after completing the still wait is to ensure that data after the wait
  88   is played correctly. Without it, sinks will consider the first buffers
  89   (x seconds, where x is the duration of the wait that occurred) to be
  90   arriving late at the sink, and they will be discarded instead of played.
  91
  92 3) For audio, 3) is the same case as 1) - there is a 'gap' in the audio data
  93    that needs to be presented, and this can be done by sending a NEWSEGMENT
  94    update that moves the start time of the segment to the next timestamp when
  95    data will be sent.
  96
  97    For video, however it is slightly different. Video frames are typically
  98    treated at the moment as continuing to be displayed after their indicated
  99    duration if no new frame arrives. In 3), it is desired to display a blank
 100    frame instead, in which case at least one blank frame should be sent before
 101    updating the start time of the segment.
 102
 103