[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 Martin Eikermann  2005-01-10 20:22 -------
On mathricks comment:

Thanks for your comments Maciej,

- IMO progressive sinks should advertise "interlaced=FALSE" - this would be
really progressive - and "interlaced=TRUE, field-layout=INTERLEAVED".
Progressive sinks should do this so they can handle nothing less than before. In
many cases elements will emit "interlaced=TRUE, field-layout=INTERLEAVED". We
still want applications to work, even they know nothing about
interlaced/progessive source material.

- Yep, my naming sucks. Yours is truely less confusing. But it should be
s/INTERLEAVED/INTERLACED/.

- Yep, I agree on the quality issue. What we just can not do is change a plugin
in a way that it emits single fields to elements which don't know anything about
it. And that all the way downstream. Consider the following pipeline: A -> B ->
C -> D. A can emit incidental fields. D doesn't know about buffer-fields. C does
know, but just forwards them after processing. It must be known to A that some
element downstream can not handle buffer-fields. Is this possible with caps? Yes
, there is a decent caps/negotiation document missing.

- Usually that artificially interlaced media is marked with a progressive flag.
mpeg2dec, for example, will know about that, if the media was encoded correctly.
Thus it'd be mpeg2dec's job to negotiate on "interlaced=FALSE". However, that
flag can be missing. Smart deinterlacer (adaptive method) are still be able to 
identify which fields belong together.

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