[gstreamer-bugs] [Bug 163577] [RFC] Interlaced/progressive media support in GStreamer.

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=163577
 GStreamer | gstreamer (core) | Ver: HEAD CVS





------- Additional Comments From Martin Eikermann  2005-11-14 22:40 -------
1. Adding interlaced video support to gstreamer would mean that all image/video
handling elements need to be reviewed and their caps adjusted. Then e.g. a
deinterlacer works reliably in all pipelines.

Basically

    interlaced:   { TRUE, FALSE }
    field-layout: enum { INTERLEAVED, SEQUENTIAL }
and field-order:  enum { TOP_FIELD_FIRST, BOTTOM_FIELD_FIRST }

need to be added to the caps. If that's not possible to do at once for all
elements, the deinterlacer will work in some cases otherwise it would have to
act on default settings, user settings or just pass through.

Reviewed elements should have the following behaviour:
  a) Upstream peer does not have an interlaced
     caps entry.
     Assume interlaced=FALSE and do not publish
     this assumption downstream (since we do not
     know if it is really progressive).
  b) Element cares about interlacing. Negotiate
     the interlace settings and publish result
     downstream.
  c) Element doesn't care. Publish (copy) interlace
     settings to src pad(s).

In addition,
2. We need to think about incidental fields. In mpeg for example it
is possible that a single bottom/top field has been muxed into the stream. The
problem is that the mpegdemuxer can't just create a buffer and send that single
field downstream. How is xvimagesink supposed to handle a single field? It can't
(in a sane way). In any case xvimagesink needs to know that this buffer holds
only one field. I agree with Maciej that a custom GstBufferFlag would be the
best way to solve this. But even then, _all_ video/* handling elements _must_
check for this flag, and at least drop the single field if they can't handle it.


I can't think of pipelines, that will fail if changes under 1. are applied
incrementally. I'm not sure if addition to caps will violate the freeze. If
they do, it won't be doable in 5 days for 0.9.
Changes under 2. will require at least the custom GstBufferFlag in the core.
It won't harm sitting just there. But with the first element emitting single
fields, all elements must be made aware of this.


I hope this is a bit more concise summary what needs to be done to get proper
interlacing support into gstreamer.

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.