[gstreamer-bugs] [Bug 629165] interlace: Add telecine mode support

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #6 from Robert Swain <robert.swain at gmail.com> 2010-09-18 12:39:21 UTC ---
Being able to telecine content in the same element as one can interlace content
doesn't inhibit any of what you're discussing. Code can be shared between the
interlacing and telecine processes. I understand the difference you're
detailing between the non-destructive (inverse) telecine process and
(de)interlacing, but I don't think it's harmful to have them all under one
roof.

I haven't considered all avenues for the * -> plain progressive conversion by
any means. For field analysis, considering whether two opposing parity fields
are progressive or not is something common to both interlace and telecine
detection.

As content/encoding can vary within one stream, if we separate the analyses, we
may either need to perform the same analyses twice or have less information
available. Perhaps some of the information is irrelevant. Contextual
information however is probably essential for managing transitions between
content/encoding types in an input stream.

Unless you're considering that for a generic
handle-it-all-and-output-progressive pipeline one must ivtc first and then
adaptively deinterlace, making both ivtc and deinterlace pass-through
progressive frames, ivtc reconstructs progressive content from telecined
encodings and deinterlace just deinterlaces interlaced frames that were passed
through ivtc.

I'm not really sure what I think is best so I'm going to reread this on Monday.
:)

-- 
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.