GNOME Bugzilla – Bug 767601
Missing State Notifications From Playbin
Last modified: 2016-06-23 07:36:05 UTC
Created attachment 329679 [details] Program that reproduces the bug once in a while, rerun till it does I set a uri on playbin based pipeline, set state to paused, then after a while to playing. I have a bus connected waiting for GST_MESSAGE_STATE_CHANGED from pipeline. Sometimes all expected state changes arrive, sometimes I only get the first state change (NULL->READY) leaving my application without knowledge that the video is actually playing. Note that the video IS playing in the video. This seems to be related only to notifying about the state change. I have attached a small windows program that will reproduce the problem like 1 out of 10 or something. The program will exit the process if it gets the state change, so if the main loop manages to wait 10 seconds without the state change having occurred the problem has been reproduced. The video I used was an H264 encoded video in 1920x816 resolution. I don't know if it can be reproduced with all videos and/or audio files, but I have seen it with other videos as well.
Created attachment 329681 [details] Same testcase but using only GLib APIs This works fine on Linux it seems, so it might be a Windows specific problem
Can you also get a *full* GST_DEBUG=6 debug log of a run where it never notifies about PAUSED->PLAYING?
Created attachment 329684 [details] Log for GST_DEBUG=6 Result seems different with DEBUG=6.
If I set GST_DEBUG=6 the results are different. The video will no longer start running at all. I also don't get the callback. This happens every time. With GST_DEBUG=4 I cannot reproduce the problem. Tried like 30 times or so.
Ok, so someone will have to debug this on Windows then :) I'll check when I'm back home end of the week and have access to Windows again, unless someone else is faster.
I can't reproduce this here on Windows either. So you'll somehow have to get a backtrace of all threads when it hangs, or a full debug log with level 6. As you said that it hangs when using GST_DEBUG=6, a backtrace of all threads when that happens would also be useful to get. You'll have to use gdb to do that in any case.
Is it possible that problems arise from building the source wrong? Can you paste the command line you use for building the attached app? Otherwise, I'll see what I can come up with. I don't have gdb, as I'm building with Visual Studio 2013, but I'll check up on it.
In case it's any help, here's the compile and link commands that I use. I tried shaving it down as much as I could, but issue still happens. Compile: cl.exe /c /nologo /TP /W3 /EHsc /WX /GS /RTCs /RTCu /Z7 /DDEBUG /MTd /D_USING_V110_SDK71_ /DWIN32_LEAN_AND_MEAN /DWIN32 /DNOMINMAX /D_CRT_SECURE_NO_WARNINGS /D__STDC_CONSTANT_MACROS /D__STDC_LIMIT_MACROS /DCW_THREAD_LOCAL=__declspec(thread) /DCW_DEBUG /D__CPLUSPLUS /DCW_ENDIAN_LITTLE /DCW_PLATFORM_WIN32 /ID:\gstreamer\1.8.1/x86/include/gstreamer-1.0 /ID:\gstreamer\1.8.1/x86/lib/gstreamer-1.0/include /ID:\gstreamer\1.8.1/x86/include/glib-2.0 /ID:\gstreamer\1.8.1/x86/lib/glib-2.0/include /ID:\dev\codebox\.cex\CompilerWin32\2013.4.cw4/include /ID:\dev\codebox\.cex\CompilerWin32\2013.4.cw4/ide/include /ID:\dev\codebox\.cex\CompilerWin32\2013.4.cw4/ide/PlatformSDK/include /ID:\dev\codebox\.cex\CompilerWin32\2013.4.cw4/ide/PlatformSDK/include/atl /ID:\dev\codebox\.cex\CompilerWin32\2013.4.cw4/ide/WDK/include Tests/StateTestWin32.cpp /Foout/win32-debug/StateTestWin32/StateTestWin32/obj/StateTestWin32.obj Link: link.exe /NOLOGO /OUT:out/win32-debug/bin/StateTestWin32.exe /DEBUG out/win32-debug/StateTestWin32/StateTestWin32/obj/StateTestWin32.obj /LIBPATH:D:\dev\codebox\.cex\CompilerWin32\2013.4.cw4/ide/lib /LIBPATH:D:\dev\codebox\.cex\CompilerWin32\2013.4.cw4/ide/PlatformSDK/lib /LIBPATH:D:\dev\codebox\.cex\CompilerWin32\2013.4.cw4/ide/WDK/lib /LIBPATH:D:\gstreamer\1.8.1/x86/bin/libbz2.dll /LIBPATH:D:\gstreamer\1.8.1/x86/bin/libfaad-2.dll /LIBPATH:D:\gstreamer\1.8.1/x86/bin/libgio-2.0-0.dll /LIBPATH:D:\gstreamer\1.8.1/x86/bin/libgmp-10.dll /LIBPATH:D:\gstreamer\1.8.1/x86/bin/libgnutls-30.dll /LIBPATH:D:\gstreamer\1.8.1/x86/bin/libgstaudio-1.0-0.dll /LIBPATH:D:\gstreamer\1.8.1/x86/bin/libgstbase-1.0-0.dll /LIBPATH:D:\gstreamer\1.8.1/x86/bin/libgstreamer-1.0-0.dll /LIBPATH:D:\gstreamer\1.8.1/x86/bin/libgsttag-1.0-0.dll /LIBPATH:D:\gstreamer\1.8.1/x86/bin/libhogweed-4-2.dll /LIBPATH:D:\gstreamer\1.8.1/x86/bin/libnettle-6-2.dll /LIBPATH:D:\gstreamer\1.8.1/x86/bin/liborc-0.4-0.dll /LIBPATH:D:\gstreamer\1.8.1/x86/bin/libtasn1-6.dll /LIBPATH:D:\gstreamer\1.8.1/x86/bin/libz.dll D:\gstreamer\1.8.1/x86/lib/gstreamer-1.0.lib D:\gstreamer\1.8.1/x86/lib/glib-2.0.lib D:\gstreamer\1.8.1/x86/lib/gobject-2.0.lib
This should be unrelated to how it was built, it's probably a race condition in the GstBus code that happens on your machine but not mine due to different timings. Please get backtraces with gdb, thanks! Even if you build your application with MSVC, GStreamer is currently built with mingw and gdb has to be used for getting useful backtraces then. You can use gdb on a MSVC compiled application, it will only show wrong information for the parts that are compiled by MSVC but inside GStreamer it will all be ok.
This might be a duplicate of bug #750397
That one also has a new patch now, please test it and report back
(In reply to Sebastian Dröge (slomo) from comment #11) > That one also has a new patch now, please test it and report back Would that patch be included in any windows-build? I'm building against prebuilt windows binaries, not able to compile from source. It does sound very much like what's happening to me though.
I could put 32 bit or 64 bit binaries up somewhere for you for testing. Which one do you need? The patch would be included once it's clear that it solves the problem(s) and doesn't introduce new ones.
32 bit. Very nice of you, thanks.
https://coaxion.net/~slomo/libgstreamer-1.0-0.dll Let me know when you got it so I can delete it again
Got it. Will test now.
With the patch I cannot reproduce the issue with the app attached to this issue. Tried 200 runs. Without the patch it happened after at most 35 runs. Sometimes less than 10. I will try with my main player app, see how it goes there.
From what I can tell the patch fixes the problem and doesn't introduce any sideeffects that I have noticed. But my use-case is quite simple (I only use the bus to obtain state changes).
Thanks, let's close it as a duplicate then :) *** This bug has been marked as a duplicate of bug 750397 ***