GNOME Bugzilla – Bug 741608
d3dvideosink: Pipeline crash after assigned Window minimized
Last modified: 2015-12-01 13:10:38 UTC
Environment: Windows 8.1 GStreamer: 1.4.4 pipeline: gst-launch-1.0.exe -v filesrc location=d:\t.avi ! decodebin name="dec" ! d3dvideosink dec. ! audioconvert ! autoaudiosink Whenever I minimize the appearing Window a Gst.Error apears: 0:00:17.559373887 8772 055B4000 ERROR d3dvideosink d3dhelpers.c:1452:d3d_resize_swap_chain:<autovideosink-actual-sink-d3dvideo> Error creating swapchian HRESULT: HR-SEV:1 HR-FAC:7 HR-CODE:87 0:00:17.578525902 8772 0E89C3A0 INFO d3dvideosink d3dhelpers.c:1837:d3d_render_buffer:<autovideosink-actual-sink-d3dvideo> Render 0:00:03.336666666 0:00:17.578606918 8772 0E89C3A0 ERROR d3dvideosink d3dhelpers.c:1391:d3d_resize_swap_chain:<autovideosink-actual-sink-d3dvideo> Direct3D swap chain does not exist 0:00:17.579178429 8772 0B745CB0 WARN qtdemux qtdemux.c:4434:gst_qtdemux_loop:<qtdemux1> error: streaming stopped, reason error BTW 1: Change 'd3dvideosink' to 'glimagesink' and everything works like a charm. BTW 2: Same behavior with a custom output Handle within application
Created attachment 307197 [details] modified plugin source files Environment: Windows 7 x64 Gstreamer: 1.5.2 I can confirm that this bug still exists. I'm developing a Qt application where I'm setting a rendering window with gst_video_overlay_set_window_handle and d3dvideosink. Everything works fine until I minimize and maximize application window. After that I'm getting "internal data flow error". I managed to get rid of this error in an ugly way. These are my steps: 1. I copied source files of d3dvideosink from gst-plugins-bad-1.5.2 directory to my project, 2. I changed the plugin so it can be loaded inside my application (renamed it to d3dvideosink_wb, renamed class, added a function to invoke plugin_init, commented GST_PLUGIN_DEFINE... part), 3. Fixed some windows specific warnings. After that I put d3dvideosink_wb into my pipeline and now the problem with minimalization is gone! I didn't change much but it worked somehow. I hope someone smarter than me can look at this.
Can you attach a diff/patch of the source files to allow easier review, without the renaming changes?
Created attachment 307214 [details] [review] patch I attached a patch file (without renaming changes).
Review of attachment 307214 [details] [review]: ::: orig/d3dhelpers.c @@ +724,3 @@ + //return + GST_BUFFER_POOL_CLASS + (gst_d3dsurface_buffer_pool_parent_class)->release_buffer (bpool, buffer); This is the only change that should make a difference... you should be leaking all buffers now :)
(In reply to Sebastian Dröge (slomo) from comment #4) > Review of attachment 307214 [details] [review] [review]: > > ::: orig/d3dhelpers.c > @@ +724,3 @@ > + //return > + GST_BUFFER_POOL_CLASS > + (gst_d3dsurface_buffer_pool_parent_class)->release_buffer (bpool, buffer); > > This is the only change that should make a difference... you should be > leaking all buffers now :) I commented only return keyword so the rest (GST_BUFFER...) is still there uncommented.
Oops, indeed. How does that make a difference though? This needs some further debugging :)
commit d8b1efe13ab2d366290573f4cecbd0852a2721c5 Author: Sebastian Dröge <sebastian@centricular.com> Date: Mon Nov 30 19:53:28 2015 +0200 d3dvideosink: Don't try to recreate swapchain while the window is minimized It will fail and cause the sink to crash. Instead wait until the window is visible again before checking if the swapchain really has to be recreated. https://bugzilla.gnome.org/show_bug.cgi?id=741608