GNOME Bugzilla – Bug 726026
d3dvideosink: D3d surface not released when pipeline is set to GST_STATE_NULL
Last modified: 2016-06-15 11:05:32 UTC
Created attachment 271412 [details] d3dvideosink log Hi the following sample show the D3D window not being released when the pipeline is set to GST_STATE_NULL, thus, the pipeline cannot be set to playing again : {{{ #include <gst/gst.h> #include <windows.h> GstPipeline *pipeline = NULL; int _tmain(int argc, _TCHAR* argv[]) { GError *theError; GMainLoop *theMaineLoop; SetEnvironmentVariable(L"GST_DEBUG", L"d3dvideosink:6"); if(!gst_init_check(NULL, NULL, &theError)) { printf("failed to initialize gstreamer : %s\n", theError->message); return -1; } pipeline = GST_PIPELINE(gst_element_factory_make("playbin", NULL)); g_object_set(G_OBJECT(pipeline), "uri", "file:///c:/DLNA_Media_Base/O-AVCTS_NA_I-04.ts", NULL); theMaineLoop = g_main_loop_new( NULL, FALSE ); if(gst_element_set_state(GST_ELEMENT(pipeline), GST_STATE_PLAYING) == GST_STATE_CHANGE_FAILURE) { printf("Failed to gst_element_set_state."); return -1; } else { printf("sleeping for 5s\n"); // Video should be playing Sleep(5000); printf("setting pipeline to state NULL (and sleep 5s)\n"); // Window should close but doesn't gst_element_set_state(GST_ELEMENT(pipeline), GST_STATE_NULL); Sleep(5000); printf("setting pipeline to state PLAYING (and sleep 5s)\n"); gst_element_set_state(GST_ELEMENT(pipeline), GST_STATE_PLAYING); // Will fail playing the video again unless you manualy close the window printf("running main loop\n"); g_main_loop_run(theMaineLoop); printf("finished running main loop\n"); } gst_deinit(); return 0; } }}} Regards, Eric T
Hi, I am having a look at this bug now that I'm able to build gstreamer under windows. I was wondering if it is normal to have : d3dvideosink:GstD3DVideoSink:d3d_release_swap_chain(1335): D3D surface released. Ref count: 1 d3dvideosink::d3d_class_display_device_destroy(2424): Direct3D device [adapter:0] released. Reference count: 7 d3dvideosink::d3d_class_destroy(2300): Direct3D object released. Reference count: 1 when the pipeline is going to GST_STATE_NULL. Also, if I play again, the second time, the sink will ceate his own window in stead of using the QtWidget (has for the first time) And then at the tird play, it will fail registering it window class. d3dvideosink::d3d_class_init(2222): Failed to register window class: 1410 If anybody have an idea or a starting point to investigate on this? eric
From my latest investigation, it looks like the hidden_window's thread doesn't quit when stoping whereas it does when we close the window...
I think I found the problem, the internal_window_thread never quit when stopping, was able to fix by posting WM_QUIT message to the window when setting it to NULL. I'll test more that it doesn't break anything and make a git patch
Created attachment 273575 [details] [review] Patch that should fix this issue and more This patch fixes the issue that internal windows thread didn't qui when setting pipeline to GST_STATE_NULL Also fixes an issue when using a provided window handle. This handle was lost when setting the pipeline to GST_STATE_NULL, thus when the pipeline was set to GST_STATE_PLAYING again, the videosink created a new window.
Ps : I couldn't indent the source correctly, when calling gst-indent, it made the whole files different...
Created attachment 273577 [details] [review] Patch that should fix this issue and more Replace the previous patch, I forgot that I had rename the element
Review of attachment 273577 [details] [review]: Basically looks good, but: ::: sys/d3dvideosink/d3dhelpers.c @@ +1821,2 @@ (sink->d3d.window_handle != NULL) ? "Render" : "No Win", + GST_TIME_ARGS (GST_BUFFER_TIMESTAMP (buf)));*/ Why do you comment this out?
My mistake, I must have commented it while debugging to have less log flood
Eric, can you provide a new patch? :)
commit f54efc206f0d62d0689d45d9e755224f9416e33d Author: Eric Trousset <etrousset@awox.com> Date: Mon Jun 23 20:44:23 2014 +0200 d3dvideosink: Release D3D surfaces when shutting down the sink https://bugzilla.gnome.org/show_bug.cgi?id=726026
Hi, sorry, I didn't get time to take care of this, thx for the commit. Regard, Eric T
*** Bug 712592 has been marked as a duplicate of this bug. ***