- This does not look like a GStreamer error message at first glance

 - This file plays fine for me with current releases and CVS. This
   has been fixed ~ gst-plugins-good 0.10.3 time AFAIK.

 - What's the output of
     $ gst-inspect-0.10 pngdec | grep Version
     $ gst-inspect-0.10 qtdemux | grep Version

 - Is this with qtdemux from -bad or the fluendo iso demuxer?

Brain crap. I rebuilt totem against xine-lib after testing the configure.in changes to make GStreamer the default ;)

Ha, instead I get:
Failed to create output image buffer of 90x72 pixels

(Don't know what I was thinking).

Using gstreamer-plugins-good-0.10.4-1.fc6, and without the iso demuxer installed.

pngdec:
Factory Details:
  Long name:    PNG image decoder
  Class:        Codec/Decoder/Image
  Description:  Decode a png video frame to a raw image
  Author(s):    Wim Taymans <wim@fluendo.com>
  Rank:         primary (256)

Plugin Details:
  Name:                 png
  Description:          PNG plugin library
  Filename:             /usr/lib/gstreamer-0.10/libgstpng.so
  Version:              0.10.4
  License:              LGPL
  Source module:        gst-plugins-good
  Binary package:       Fedora Core gstreamer-plugins-good package
  Origin URL:           http://download.fedora.redhat.com/fedora

GObject
 +----GstObject
       +----GstElement
             +----GstPngDec

Pad Templates:
  SRC template: 'src'
    Availability: Always
    Capabilities:
      video/x-raw-rgb
                    bpp: 32
                  depth: 32
             endianness: 4321
               red_mask: -16777216
             green_mask: 16711680
              blue_mask: 65280
             alpha_mask: 255
                  width: [ 1, 2147483647 ]
                 height: [ 1, 2147483647 ]
              framerate: [ 0/1, 2147483647/1 ]
      video/x-raw-rgb
                    bpp: 24
                  depth: 24
             endianness: 4321
               red_mask: 16711680
             green_mask: 65280
              blue_mask: 255
                  width: [ 1, 2147483647 ]
                 height: [ 1, 2147483647 ]
              framerate: [ 0/1, 2147483647/1 ]

  SINK template: 'sink'
    Availability: Always
    Capabilities:
      image/png


Element Flags:
  no flags set

Element Implementation:
  No loopfunc(), must be chain-based or not configured yet
  Has change_state() function: 0x500dc0
  Has custom save_thyself() function: gst_element_save_thyself
  Has custom restore_thyself() function: gst_element_restore_thyself

Element has no clocking capabilities.
Element has no indexing capabilities.

Pads:
  SRC: 'src'
    Implementation:
    Pad Template: 'src'
  SINK: 'sink'
    Implementation:
      Has chainfunc(): 0x502020
      Has custom eventfunc(): 0x500e70
    Pad Template: 'sink'

Element Properties:
  name                : The name of the object
                        flags: readable, writable
                        String. Default: null Current: "pngdec0"

qtdemux:
Factory Details:
  Long name:    QuickTime demuxer
  Class:        Codec/Demuxer
  Description:  Demultiplex a QuickTime file into audio and video streams
  Author(s):    David Schleef <ds@schleef.org>
  Rank:         primary (256)

Plugin Details:
  Name:                 qtdemux
  Description:          Quicktime stream demuxer
  Filename:             /usr/lib/gstreamer-0.10/libgstqtdemux.so
  Version:              0.10.3
  License:              LGPL
  Source module:        gst-plugins-bad
  Binary package:       GStreamer Bad Plug-ins source release
  Origin URL:           Unknown package origin

GObject
 +----GstObject
       +----GstElement
             +----GstQTDemux

Pad Templates:
  SINK template: 'sink'
    Availability: Always
    Capabilities:
      video/quicktime
      audio/x-m4a
      application/x-3gp

  SRC template: 'audio_%02d'
    Availability: Sometimes
    Capabilities:
      ANY

  SRC template: 'video_%02d'
    Availability: Sometimes
    Capabilities:
      ANY


Element Flags:
  no flags set

Element Implementation:
  No loopfunc(), must be chain-based or not configured yet
  Has change_state() function: 0x12ae40
  Has custom save_thyself() function: gst_element_save_thyself
  Has custom restore_thyself() function: gst_element_restore_thyself

Element has no clocking capabilities.
Element has no indexing capabilities.

Pads:
  SINK: 'sink'
    Implementation:
      Has chainfunc(): 0x129be0
      Has custom eventfunc(): 0x1211d0
    Pad Template: 'sink'

Element Properties:
  name                : The name of the object
                        flags: readable, writable
                        String. Default: null Current: "qtdemux0"

> Failed to create output image buffer of 90x72 pixels

Looks like a problem ximagesink or xvimagesink. Could you do this:

 $ GST_DEBUG=*imagesink:5 totem moveyourfeet.mov 2>dbg.log

and attach the log?

Also, what's the version of gst-plugins-base?

Created attachment 76922 [details]
dbg.log

Here goes

From the log:

Creating new XvImageBuffer
creating 90x72
XShm image size is 19440
XServer ShmAttached to 0x462801e, id 0x3e00003
error: Failed to create output image buffer of 90x72 pixels
error: XServer allocated buffer size did not match input buffer

The image size looks wrong (19440/72 = 270). Looks to me like xvimagesink doesn't calculate or query the stride properly for RGB caps with certain widths.

"The image size looks wrong (19440/72 = 270). Looks to me like xvimagesink
doesn't calculate or query the stride properly for RGB caps with certain
widths."

... which is probably lucky - the last time I tried RGB caps into xvimagesink (which only works on ATI cards with x.org drivers afaik), it crashed the X server because that code path in the driver was actually completely untested.

That fix might have been released and made it into your distro by now though.

Good thing we made xvimagesink advertise RGB caps in the first place then ...

This is likely an X bug, since every overlay hardware I've seen requires strides in multiples of 4.  270 isn't a multiple of 4.

The XV extension is pretty craptastic in this area.  We could attempt to deduce the stride from the SHM size / height, and when it's wrong, assign the blame to X with a little more confidence than "huh.  must be an X bug".

I added some code for sanity checking the size number we get back from X.  It only works for YUV variants currently, because I can't remember what the ID codes for RGB XVideo are.

It outputs a GST_WARNING(), which may not be exactly what we want.

To actually fix this problem, we might as well just turn off RGB XVideo.  I don't think anyone uses it productively.

Not sure if this is fixed with latest CVS... but I can't reproduce it at all. Works fine with xvimagesink with either rgb or yuv input.

Can someone still reproduce this?

Nowadays I get no sound, and still a very very dodgy resizing in Totem.

Created attachment 113351 [details]
screenshot showing the problem

That looks like either it's not exposing the output on resize, and isn't receiving any new frames that would implicitly cause a repaint, or the window isn't being resized correctly, or the resize isn't being registered by xvimagesink.

Just to be clear, in that screenshot, it's definitely xvimagesink, not ximagesink or glimagesink or something?

(In reply to comment #14)
> That looks like either it's not exposing the output on resize, and isn't
> receiving any new frames that would implicitly cause a repaint, or the window
> isn't being resized correctly, or the resize isn't being registered by
> xvimagesink.

Possibly.

> Just to be clear, in that screenshot, it's definitely xvimagesink, not
> ximagesink or glimagesink or something?

I tested with ximagesink, just to be sure, and it does resize to the full size after a couple of frames have showed up.

Using xvimagesink, it won't resize over 9 times the original size (exactly): 90x72 -> 630x504.

The resizing works for me with ximagesink too. I don't have xvimagesink, so I can't test with that. Some debug capture of GST_DEBUG=xvimagesink:5 when resizing might help.

The lack of audio is a regression in gst-ffmpeg. With gst-ffmpeg 0.10.3, it plays fine. gst-ffmpeg CVS produces constant 'audio discontinuity' errors.

OK, I have a fix for the audio decoding regression. Testing to make sure there's no other side effects before committing.

Fix for audio is in gst-ffmpeg CVS

*** Bug 540401 has been marked as a duplicate of this bug. ***

http://www.gnome.org/~hadess/move-your-feet-resize.log.bz2

The last xvimage_put I see in there has

0:00:09.319338250 27720      0x2590d20 LOG            xvimagesink xvimagesink.c:822:gst_xvimagesink_xvimage_put:<videosink-actual-sink-xvimage> XvShmPutImage with image 90x72 and window 984x794, from xvimage 

That implies we're calling XvShmPutImage with the correct parameters - which would make me say that it has to be an X bug. Did you say somewhere that it works (using Xv) in some other player?

Can you try:

gst-launch videotestsrc ! video/x-raw-yuv,width=90,height=72 ! xvimagesink and scale it up?

(In reply to comment #21)
> Can you try:
> 
> gst-launch videotestsrc ! video/x-raw-yuv,width=90,height=72 ! xvimagesink and
> scale it up?

Yay! Borked as well.

mplayer doesn't want to playback using Xv on my machine, and xine doesn't understand the png video.

It's apparently hardware specific which maximum ratio you can get for the scaling.

Filed upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=16587

Bastien, is this still an issue ? Just tried it with intel driver 2.6.3 and it works fine.

I guess it would work using the OpenGL pipeline. Closing, thanks for the work guys.