GNOME Bugzilla – Bug 752323
d3dvideosink: instances out of sync viewing same stream
Last modified: 2018-11-03 13:37:38 UTC
Need help debugging this situation: I'm viewing 16 times the same live stream (704x576@25fps) inside the same application instance, each viewer is indipendent from others. After 15/20 seconds, the viewers goes unsynchronized by a bunch of seconds... Here is a d3dvideosink log of what is happening: Line 4167: 0:00:16.027982237 10056 12AAA500 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 4200: 0:00:16.143013838 10056 1FAFC0B0 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 4246: 0:00:16.326275554 10056 1FB10770 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 4300: 0:00:16.540716452 10056 1FB10A68 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 4353: 0:00:16.777062571 10056 12C28B20 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 4387: 0:00:16.907878760 10056 1FB10108 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 4610: 0:00:17.823888110 10056 1FB1A718 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 4614: 0:00:17.840651538 10056 1FB10748 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 4666: 0:00:18.043435521 10056 1FB1AA38 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 4670: 0:00:18.058406121 10056 1FB10130 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 4741: 0:00:18.344632643 10056 1FB1A0D8 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 4765: 0:00:18.442028456 10056 12E6E9B8 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 4824: 0:00:18.656777565 10056 1AECCE00 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 5189: 0:00:20.073670180 10056 1FB1A3F8 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 5550: 0:00:21.490712250 10056 12AAA820 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 Line 5569: 0:00:21.576102846 10056 1FB1AD58 INFO d3dvideosink d3dhelpers.c:1897:d3d_render_buffer:<video_sink> Render 4:23:36.465000000 As you can see the same frame is processed by the 16 instances in 5 seconds. Following the code, I've found a LOCK_CLASS statement in d3d_present_swap_chain, other logs here reveal that all the presenting threads are queued waiting to acquire this lock, processed one by one. At the same time, the application gui becomes unmanageable, e.g. it's almost impossible to resize the main application window. There is no problem if there are 4 instances of main application streaming 4 players each one, while no problem is registered with lower framerate cameras, even 16 player instances. This problem is not spotted in 0.10, no shared lock in the old code.
Created attachment 307355 [details] [review] d3d immediate rendering
It seems that PresentationInterval set to D3DPRESENT_INTERVAL_IMMEDIATE fixes the issue. Obviusly it raises the cpu usage, but that way all frames are rendered as expected.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/273.