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

[bugzilla-daemon at bugzilla.gnome.org]

Please DO NOT reply to this by email. All additional comments should be made in
the comments box of this bug report.

 http://bugzilla.gnome.org/show_bug.cgi?id=163577
 GStreamer | gstreamer (core) | Ver: HEAD CVS





------- Additional Comments From Maciej Katafiasz  2005-01-10 12:37 -------
Some comments:
- Progressive sinks don't really have to support interlaced=[TRUE, FALSE]. If
data comes in sequential layout, progressive sink advertising support for
interlaced video is doing wrong thing, and will display garbled data. Whether
wit supports interlaced=TRUE depends strictly on field_layout.

- top_field_first and field_order are named and typed confusingly, they should
rather be (enum)field-layout = {SEQUENTIAL, INTERLACED} and (enum)field-order =
{TOP_FIRST, BOTTOM_FIRST}. Also fields_only seems odd, wouldn't it be better as
(int)buffer-fields similar to buffer-frames used in float audio?

- I'm not sure, but incidental out-of-order field buffers may be useful for
plugins doing inverse telecine and similar things, dropping them would mean loss
of data which could be usefully consumed. So evil but we may want to support it.
I can see two ways to do it: custom GstBufferFlag denoting whether it is top or
bottom field, for which element would have to check before processing the frame,
or custom GstEvent, sent before such out-of-order field buffer to prepare
element for it. GstEvent is somewhat heavyweight, but may be appropriate if we
consider it exceptional occurence. Flag requires conscient check before doing
anything with field, but OTOH elements doing field-order sensitive processing
would need to keep currently processed field somewhere anyway, so it may incur
no additional work in the end. Flag sounds good after all, and shouldn't cause
any harm when unused.

- What about timestamps? AFAICU, there may be two situations: one where source
frames are full, and only artificially split into fields before encoding (like
anime DVD, where source is full 24fps video mastered into PAL/NTSC field data),
and one where we have truly interlaced data with fields not summing up to frames
(real TV feed for example). Should those be timestamped differently (ie.
even-odd have equal timestamp vs. even-odd have different timestamps)? That
might have influence on assumption that progressive element is always able to
process interleaved fielded data (not to mention timestamping such data becomes
difficult in the first place).

- Example negotiations would be indeed useful to check there aren't any problems
with this solution. I hope it's on TODO to deliver before finishing this RFC :)

Otherwise, with my limited knowledge of topic at hand, this proposal seems good
and rather easy to understand, except that it's yet another thing to audit all
video elements agains to check that they behave... Oh well, life sucks anyway.

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