After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 711107 - Gap functions for video track causes errors in windows.
Gap functions for video track causes errors in windows.
Status: RESOLVED DUPLICATE of bug 706584
Product: GStreamer
Classification: Platform
Component: gst-editing-services
1.2.0
Other Windows
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-10-29 22:12 UTC by Kim Lam
Modified: 2013-11-04 17:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch such that gaps will work in windows. (854 bytes, text/plain)
2013-10-29 22:12 UTC, Kim Lam
Details
debug output for bug (265.06 KB, text/plain)
2013-10-29 22:45 UTC, Kim Lam
Details

Description Kim Lam 2013-10-29 22:12:32 UTC
Created attachment 258493 [details]
Patch such that gaps will work in windows.

Either a race condition or threading issue causes video gaps to cause GES on windows to crash.  The problem can be solved by adding a queue in the gap element.

on a related note

ges-launch-1.0 +pattern snow 1.0 

Also crashes on windows. I suspect there is an issue with videotestsrc and GES on windows.
Comment 1 Tim-Philipp Müller 2013-10-29 22:23:23 UTC
Thanks for the patch, but this sounds more like a hackish workaround that likely only works by chance than a fix for the issue. Could you provide a stack trace for the crash?
Comment 2 Kim Lam 2013-10-29 22:45:02 UTC
Created attachment 258494 [details]
debug output for bug
Comment 3 Kim Lam 2013-10-29 22:46:43 UTC
I agree, it is quite the hack. The stack trace is below and I've attach a GStreamer log with GST_DEBUG=ges*:TRACE,gnl*:TRACE,*video*:TRACE

>	ntdll.dll!RtlUlonglongByteSwap()  + 0x5eaf bytes	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
 	libglib-2.0-0.dll!g_mutex_unlock()  + 0x10 bytes	
 	libgstbase-1.0-0.dll!gst_base_src_wait_playing()  + 0x2393 bytes	
 	libgobject-2.0-0.dll!g_object_unref()  + 0x81 bytes	
 	libgstreamer-1.0-0.dll!gst_mini_object_steal_qdata()  + 0x1a17 bytes	
 	libglib-2.0-0.dll!g_private_get()  + 0x15 bytes	
 	libglib-2.0-0.dll!g_rec_mutex_lock()  + 0x16 bytes	
 	libgstreamer-1.0-0.dll!gst_tag_setter_get_tag_merge_mode()  + 0x168 bytes	
 	libglib-2.0-0.dll!g_get_num_processors()  + 0x377 bytes	
 	msvcrt.dll!_endthreadex()  + 0x6c bytes	
 	kernel32.dll!BaseThreadInitThunk()  + 0x12 bytes	
 	ntdll.dll!RtlInitializeExceptionChain()  + 0x63 bytes	
 	ntdll.dll!RtlInitializeExceptionChain()  + 0x36 bytes
Comment 4 Sebastian Dröge (slomo) 2013-10-30 17:24:39 UTC
Can you provide a backtrace with proper debug symbols? If this was built with MinGW you have to use gdb instead of the MSVC debugger.
Comment 5 Kim Lam 2013-10-30 17:26:19 UTC
I'll give it a shot, I should be able to come up with a test small test program that compiles in MinGW.
Comment 6 Sebastian Dröge (slomo) 2013-10-30 17:52:21 UTC
Maybe related to bug #706584
Comment 7 Sebastian Dröge (slomo) 2013-10-30 17:52:45 UTC
Which has a patch to test btw
Comment 8 Kim Lam 2013-11-04 17:22:49 UTC
Just an update. The patch worked, and for whatever reason my system isn't giving proper backtraces.  I'll have to figure out what's wrong with my system.
Comment 9 Sebastian Dröge (slomo) 2013-11-04 17:23:45 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 706584 ***