[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





------- Comment #9 from David Schleef  2006-10-26 19:09 UTC -------
I've been thinking about this recently, too.

I like the concept of adding buffer flags.  It's clean, and expresses a
per-buffer quantity in ways that caps cannot.  (duh).  In particular, it
expresses the MPEG2 TFF and BFF flags well, and duration handles NUM_FIELDS.

I don't think it's wise to attempt to put more than 2 fields into a buffer.  I
think it's best to just to what MPEG2 does, and have two fields in the buffer,
and say what duration to display the fields, alternating between them if
necessary.  And if the duration of the buffer is only the duration of one
field, then the buffer would contain an extra unused field.

However, I've nearly convinced myself that video comprised only of fields
should have a new caps type, e.g., video/x-field-yuv.  Features would be:

  - Buffers are individual fields with durations of 1/(2*framerate)

  - Buffers must have TFF or BFF flag set.

  - Buffers would have (height/2) lines of size (width)

  - conversion to/from video/x-raw-yuv is done by interleaving/deinterleaving
scanlines of two adjacent buffers

In any case, I forsee that we'll put a "video2progressive" filter in front of
xvimagesink, which will detect interlaced video and convert fields at
(framerate) into frames at (framerate*2) (or leave progressive video
unaltered), and have xvimagesink render them appropriately.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email