[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