Created attachment 211184 [details]
Minimalistic example of choppy playback

Here is link to trailer I used for playback http://downloads.dvdloc8.com/trailers/divxdigest/simpsons_movie_1080p_trailer.zip

I've discovered very strange thing - I'm using ATI fglrx drivers (12.3) and when I removed them, cluttersink worked as it should, without any skipping frames or choppy video. That is stange behaviour and probabaly bug in cluttersink plugin.

Everything else works as expected with fglrx drivers (tested xvimagesink, fluvaclutsink).

Hi, are you sure your test is working with a recent version of clutter ?

It seems that clutter's api changed since you wrote your test.

Those 2 lines:

sink = gst_element_factory_make("cluttersink","sink");
g_object_set (sink, "texture", CLUTTER_TEXTURE (texture), NULL);

have to be replaced by:

sink = clutter_gst_video_sink_new (CLUTTER_TEXTURE (texture));

I think this is to prevent from using clutter sink from gst-launch command line (in order to make sure to initialize clutter in the main thread)

As far I am concerned, I am using clutter-v1.8 and clutter-gst-v1.4.6
and I see no choppy problem

glxinfo:

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GT 330/PCIe/SSE2
OpenGL version string: 3.3.0 NVIDIA 295.20
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler

Hi Julien,

Actually that's the opposite, in 1.5.x clutter-gst installs a real GStreamer plugin, so the "new" API is to use gstreamer's API to create the sink and then use the usual GObject properties to set the texture. cluttersink now works with gst-launch (at least for the test cases I've used).

The API difference is just to instantiate the object, no difference in behaviour.

The choppy problem could simply be that the driver is hitting a slow path, say memcpy()ing stuff around.

David, could you look at the CPU usage of your choppy pipeline? a sysprof profile would even be better!

Hi,

I've been able to reduce that choppy efect with a workaroud that reduces problems with GNOME (that has to do something with clutter) and fglrx driver.

I've disabled vsync in amdcccle and added "export CLUTTER_VBLANK=none" to /etc/environment.

Now, that effect is reduced, video is quite good, watchable, but still it is not as good as TV - probably because of limitations of Linux and drivers.

CPU usage is not different from vlc or mplayer one, I can make sysprof later if needed, I need some time to understand how it works, as I've never used that.

This is fglrxinfo on this machine, but result is same on other two machines with different AMD ATI GPU.

OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: ATI Radeon HD 5700 Series 
OpenGL version string: 4.2.11554 Compatibility Profile Context

So, probably, this is clutter bug that is not related to gstreamer and I hope that it will be resloved.

Moving to clutter proper. This could very well be a problem in the driver itself though.

does this still happen with a recent nvidia driver, Clutter, and Clutter-GStreamer releases?

Hi,

I don't know about nvidia, as I have only AMD cards here.

Also, this has nothing to do with gstreamer as gstreamer works well without clutter sink.

I believe that this is bug in fglrx or clutter itself.

By changing env variables

CLUTTER_PAINT=disable-clipped-redraws:disable-culling
CLUTTER_VBLANK=True

and forcing fglrx to vsync (in amdcccle) I manage to bypass this bug - all clutter animations now look fluid and without glitches.

Maybe that can help.

"CLUTTER_VBLANK=True" does not make any sense; the correct value is "none", and that will disable the synchronisation by using a fixed timer every 16.667 milliseconds.

so what you're really doing is disabling the clipped redraws and the internal scene graph culling, which points to a bad driver: it means that no synchronisation is performed when using glXCopySubBuffers.

I suggest opening a bug against the fglrx driver.