gst-vmeta testing

Daniel Drake dsd at
Fri Aug 23 13:20:31 EDT 2013

Hi Carlos,

I have given your gstreamer-1.0 plugins a spin on XO-4. Thanks for
working on this.

I additionally installed gstreamer1-plugins-bad-free for the mpeg4
container support and I'm testing with this video:

No audio support is installed.

Comparing gstreamer-0.10:

 gst-launch-0.10 filesrc location=hellmans_mayonnaise_commercial.mpeg
! decodebin ! vmetaxvimagesink

To your work:

 gst-launch-1.0 filesrc location=hellmans_mayonnaise_commercial.mpeg !
decodebin ! vmetaxvsink

As an initial check, vmeta does seem to be being used. I added some
prints into the X driver to check the hacky accelerated Xv path and it
is indeed hit, and the vmeta interrupts do increase during playback.

Looking at CPU usage: playing back that video at the standard size is
about 15% in both tests.

Now for human observation: there is no flicker problem. However, the
video is noticably choppier when played back in the gstreamer-1.0
environment. For example, look at the smoothness of the front door
opening in that video.

The log also fills up with:

gstbasesink.c(2705): gst_base_sink_is_too_late ():
There may be a timestamping problem, or this computer is too slow.
WARNING: from element
/GstPipeline:pipeline0/GstVmetaXvSink:vmetaxvsink0: A lot of buffers
are being dropped.

It is strange. It is not as if the CPU is too busy to keep up, after
all there is only 15% utilization. I ran it under perf (CPU-wide mode)
and that also confirmed that the system is 80% idle and didn't suggest
any obvious causes of the problem.

So, there is probably something in the gstreamer pipeline which is
doing sleep() or select() or similar, for extended time periods,
causing frames to be discarded when it wakes back up again. And
whatever it is waiting on is not eating CPU in a noticable way.

For future reference my test packaging is at

Any ideas?


More information about the Devel mailing list