deinterlace: Add support for deinterlacing using buffer caps/flags
authorRobert Swain <robert.swain@collabora.co.uk>
Mon, 8 Nov 2010 13:06:15 +0000 (14:06 +0100)
committerRobert Swain <robert.swain@collabora.co.uk>
Thu, 19 May 2011 03:45:57 +0000 (05:45 +0200)
commitc1b100cf9cbe50dd677fddef0eba68c7a195573f
treebc8592c07747a2261ce123f8a7870748d47a8ad0
parent165fbc368e1d036b5a9c64b5f8fabba9693378f4
deinterlace: Add support for deinterlacing using buffer caps/flags

When not using the fieldanalysis element immediately upstream of deinterlace,
behaviour should remain unchanged. fieldanalysis will set the caps and flags on
the buffers such that they can be interpreted and acted upon to produce
progressive output.

There are two main modes of operation:

- Passive pattern locking
  Passive pattern locking is a non-blocking, low-latency mode of operation that
  is suitable for close-to-live usage. Initially a telecine stream will be
  output as variable framerate with naïve timestamp adjustment. With each
  incoming buffer, an attempt is made to lock onto a pattern. When a lock is
  obtained, the src pad and output buffer caps will reflect the pattern and
  timestamps will be accurately interpolated between pattern repeats. This
  means that initially and at pattern transitions there will be short periods
  of inaccurate timestamping.

- Active pattern locking
  Active pattern locking is a blocking, high-latency mode of operation that is
  targeted at use-cases where timestamp accuracy is paramount. Buffers will be
  queued until enough are present to make a lock. When locked, timestamps will
  be accurately interpolated between pattern repeats. Orphan fields can be
  dropped or deinterlaced. If no lock can be obtained, a single field might be
  pushed through to be deinterlaced.

Locking can also be disabled or 'auto' chooses between passive and active
locking modes depending on whether upstream is live.
gst/deinterlace/gstdeinterlace.c
gst/deinterlace/gstdeinterlace.h