[Bug 659322] Videomixer with size changing support as parameter.

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Sat Sep 17 13:30:46 PDT 2011


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

--- Comment #6 from Jaka Hudoklin <jakahudoklin at gmail.com> 2011-09-17 20:30:44 UTC ---
I see what you think, but this way you would have to make static output caps
from videoscale element and you won't be able to scale beyond original size, or
you have to crop(this does not present a real problem). This is more like
videobox element with resizing capabilities as videscale, but i think this two
elements(videscale and videobox) should be combined, forming one  well made
videoresize element. Meybe i will make someday when i will have too mouch time.

While i support your idea, i still think that videomixer should receive my
patch, since it would make life much easier to many users, and that's actually
the only basic option that videmoxer fails. The fact is you can always throw it
out when you came up with nicer solution. If you look from minimalistic aspecp
videomixer shouldn't even have to have xpos and ypos properties nor alpha, but
they are there, well the only property videomixer must have is z-index,
everything else should be covered in other elements. 
If you look from other direction, why not keep all these stuff in and give
users more options to make same thing. Well if you take this path you have to
make sure you keep processing in elements optimized, so that additional options
don't slow down processing if you don't use them.

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


More information about the gstreamer-bugs mailing list