#12644 HIGH 13.2.0: vmeta playback is unreliable with the vmetaxv optimization

[Zarro Boogs per Child]

#12644: vmeta playback is unreliable with the vmetaxv optimization
---------------------------------------+------------------------------------
           Reporter:  dsd              |       Owner:  dsd          
               Type:  defect           |      Status:  new          
           Priority:  high             |   Milestone:  13.2.0       
          Component:  x window system  |     Version:  not specified
         Resolution:                   |    Keywords:               
        Next_action:  diagnose         |    Verified:  0            
Deployment_affected:                   |   Blockedby:               
           Blocking:                   |  
---------------------------------------+------------------------------------

Comment(by dsd):

 The vmetaxvimagesink plugin is at fault and removing it will work around
 this bug (with a certain loss in performance).

 The vmetaxv plugin tries to speed up video playback, by realising when
 video frames that need to be shown on-screen have come from the vmeta
 decoder. This means that they already have a known physical address. So
 there is no need to copy such image data into a new buffer (as xvimagesink
 would do), we can just pass the physical address directly and have the
 image shown on screen.

 This sounds sensible but the implementation really isn't. It is all done
 through Xv, but instead of copying the image data into a buffer passed to
 Xv, it simply sets a magic bytestring and writes the physical address
 where the image data normally would be, then calls XvShmPutImage(). The X
 driver receives this, notices the magic, handles it correctly, and changes
 the magic value to a second value to be passed back to the client. The
 client realises that the magic has changed and goes ahead and frees the
 buffer.

 The problem here is that XvShmPutImage() sometimes returns without drawing
 the image on screen, without even invoking the Xv part of the X driver. It
 commonly does this as totem is starting up, the first few calls don't seem
 to "make it through" to the driver, maybe the video area is not visible
 yet. So the magic value does not get changed, which causes the vmetaxv
 driver not to free the buffer. This happens more than 16 times during
 totem startup, which means we run out of buffers, and since we never free
 them, things go wrong from that point.

 It does not seem possible to detect if XvShmPutImage() actually sent its
 operation to the driver or not. There are times when the driver does not
 receive the request during the XvShmPutImage() call and the frame doesn't
 even get drawn in the time that follows, so busy looping waiting for the
 draw is not realistic (it would have to have a nasty timeout). Also I have
 seen cases during totem startup where it returns before the driver has
 drawn it, but then the driver does come along and draw it later. This
 system is inherently racy and needs a redesign (hopefully a better
 design...).

 For now I think it is safe for the vmetaxv code simply to free the buffer
 after sending to to XvShmPutImage(), even if the Xv driver has not sent it
 to the screen (i.e. the magic value has not been changed). As I have seen
 cases where the drawing is simply delayed, this does introduce a risk of
 drawing stale data to the screen. But at least the stale data comes from a
 known memory area and I don't see this being problematic.

-- 
Ticket URL: <http://dev.laptop.org/ticket/12644#comment:7>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system