[gstreamer-bugs] [Bug 617045] [caps] New method for intersecting caps while retaining order

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=617045
  GStreamer | gstreamer (core) | git

Mark Nauwelaerts <mnauw> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mnauw at users.sourceforge.net

--- Comment #17 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2010-08-19 07:58:04 UTC ---
(In reply to comment #15)
> The problem is, that you don't always know if the upstream or downstream order
> should be preffered. And if the order is for quality or performance or some
> other metric.

Would that not be up to the caller to know what/where it is using it (and as
such use the arguments in proper order)?

> 
> (You said that downstream order should be preffered but there are cases where
> this isn't optimal, i.e. if you have a source that can output all video formats
> but internally only uses a single one and then converts... but much slower than
> ffmpegcolorspace)

We might come up with algorithms to cover this case, but how we are going to be
aware of and express the above situation (i.e. input the proper parameters/data
to it) is not evidently clear to me.

In the meantime, it's not even complex pipelines going down the drain, but even
pulsesrc ! audioconvert ! alawenc ! fakesink (or comparable)
has float coming out pulsesrc, which is most unlikely (hardware) desirable.

Basetransform code specifically seem written given preference to one of the
caps (e.g. downstream), and it seems unlikely the proposed intersection order
will make matters worse (at least there).

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