[gstreamer-bugs] [Bug 345207] [xvimagesink] negotiation error with width of 1600
GStreamer (bugzilla.gnome.org)
bugzilla-daemon at bugzilla.gnome.org
Sun Jan 7 10:38:40 PST 2007
Do not reply to this via email (we are currently unable to handle email
responses and they get discarded). You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=345207
GStreamer | gst-plugins-base | Ver: 0.10.7
------- Comment #11 from Tim-Philipp Müller 2007-01-07 18:37 UTC -------
> Well if the XV driver refuses to create an XVImage of that size what should
> happen ?
As I understand it, it depends on the circumstances:
- if we're trying to render a frame received in our chain/render function,
all we can do is error out (and maybe investigate why we weren't able
to advertise our caps correctly in the first place)
- if we're creating an image because upstream has done a
gst_pad_alloc_buffer(), then we should allocate the largest we can
do and return that buffer with the changed caps. It is then up to
upstream to either accept that or do something else. If upstream
is a videoscale, it should just scale down to whatever the
biggest our video card/driver can do is.
Right? (Wim?)
> I guess somehow it should refuse to negotiate so that autovideosink uses
> ximagesink in that instance ?
If I'm not mistaken, this all takes place after autovideosink has already
chosen a sink. I don't think we have a mechanism yet to provide more
information to autovideosink (not should it really be necessary).
> Maybe we should have a better error message for that case..
In the absence of driver bugs we should always be able to advertise our caps
correctly in the first place and never run into this problem, shouldn't we?
--
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
More information about the Gstreamer-bugs
mailing list