Is that an ogg audio file (ogg/vorbis) or an ogg video file?

What application are you using? (totem, rhythmbox, etc.)

What's your gst-plugins-base version? You can find out by typing

 $ gst-inspect-0.10 playbin | grep Version

on a command line.

It's an ogg video file, I'm using totem and the gst-plugins-base version is 0.10.7 (so I also changed the version in the bug)

Could you run totem from the command line like this:

 $ export GST_DEBUG_NO_COLOR=1
 $ export GST_DEBUG=*:5
 $ totem yourfile.ogg  2> dbg.log
 ... wait for error, then quit totem ...
 $ gzip dbg.log

and then attach the dbg.log.gz file to this bug report please?

Created attachment 67642 [details]
Bug report

Was the file useful?

> Was the file useful?

Yes, thank you.

Looks like the video is too wide for Xv/your driver or we don't handle this right:

  xvimagesink.c(1602):gst_xvimagesink_setcaps: intersection returned video/x-raw-yuv, format=(fourcc)I420, width=(int)1600, height=(int)226, framerate=(fraction)20/1, pixel-aspect-ratio=(fraction)1/1

  xvimagesink.c(514):gst_xvimagesink_xvimage_new: XShm image size is 244080
  xvimagesink.c(1864):gst_xvimagesink_show_frame: could not create image
  xvimagesink.c(1866):gst_xvimagesink_show_frame: error: Failed creating an XvImage in xvimagesink chain function.


There have been some changes recently - any chance you could try with a current version of gst-plugins-base (=0.10.8)?

FWIW, you can probably circumvent the problem by selecting "X Windows (No Xv)" (=ximagesink) for video output in the Multimedia System Selector (but CPU usage will be quite a bit higher then).


Something for our xvimagesink experts ...

I tried changing to "X Windows (No Xv)" and it worked and the CPU usage wasn't higher than normal, thank you very much

As soon as I try the 0.10.8 I'll let you know

ping?

> ping?

There is a debug log. Any other info you need?

I don't know that much about xvimagesink, so I was hoping someone else could have a look ...

Well if the XV driver refuses to create an XVImage of that size what should happen ?

I guess somehow it should refuse to negotiate so that autovideosink uses ximagesink in that instance ?

Maybe we should have a better error message for that case..

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

Doesn't xvimagesink handle this correctly now through caps ? With a videoscale in front of the sink, it should scale down to whatever the videosink can support.

Benzo, can you try this again (if you still have the same machine).

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!