<div dir="ltr">I also think there might be a pthread thing -- I'm not sure it mixes well with .NET threads/fibers. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 5, 2019 at 5:47 PM David Ing <<a href="mailto:ding@panopto.com">ding@panopto.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Yes, you can download PDB files with the published MSVC build for version 1.16.0 here:  

<a href="https://gstreamer.freedesktop.org/download/" target="_blank">https://gstreamer.freedesktop.org/download/</a>  I typically install the runtime installer and the development installer (the PDB files come from one of those).  You will notice that some modules don't have a *.pdb files (those are probably built with mingw).</div><div><br></div><div><div>We are eliminating C++ CLI because we are targetting .NET Core and migrating to Linux (from Windows).  We are P-Invoking everything because C++ CLI isn't friendly with .NET Core (and Linux).  We have observed VS Debugger heap corruption, even when using P-Invoke (without any C++ CLI whatsoever).  But our errors go away when the VS Debugger is taken out of the equation.  And we can use the VS Debugger if Native Code Debugging is turned off.  I agree that it might be a "mingw" thing because I am using "ucrtbase.dll" and not "msvcrt.dll".</div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 5, 2019 at 2:54 PM Ben Rush <<a href="mailto:ben@ben-rush.net" target="_blank">ben@ben-rush.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">A few remarks: <br><br>1) You said "now that *.pdb files are available", is this when we build it ourselves or are they actually available for download? If they're available for download, I would love to have them as I'm encountering an issue right now that could benefit from the insight a nice stack trace would offer (perhaps I simply missed the PDBs somewhere), <br>2) In terms of managed code interop'ing with GStreamer: yes, I have noticed this as well. However, I'm not convinced it's simply GStreamer, but I think anything that is perhaps built with mingw, and I'm not sure as though it's simply the debugger, as I have noticed a great many access violations when wrapping Gstreamer in C++ CLR. In fact, I had to rewrite our entire product to be native VC++ from C++ CLR due to the random errors I was getting. The code didn't really change (it was in C++, after all), but it was just no longer accessible from C# and no longer was blowing up randomly. <br><br>I'm hoping I can help improve this platform for Windows. Because it's a damn cool platform. I just need it to run better on Windows. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 5, 2019 at 4:26 PM David Ing <<a href="mailto:ding@panopto.com" target="_blank">ding@panopto.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I have observed that most of the core Gstreamer developers use Fedora 30, and they don't really have a chance to notice Windows-specific problems.  I think they tend to focus on Linux (especially Fedora 30).  But one of the core developers (Nirbheek from Centricular) has done a lot of work on getting the MSVC build to work.<div><br></div><div>Community members (like us) should try to report and help with Windows stuff.  This is easier now that *.pdb files are available.</div><div><br></div><div>I definitely notice better performance and fewer bugs when I run on Fedora 30 (compared to Windows).  I am not sure why performance is better on Linux.  It might have something to do with the ORC (runtime compiler for inner loops), but I am just guessing.  I have also noticed that the VS debugger causes some kind of heap corruption when debugging a process which contains managed together with native gstreamer code (mingw).  Take away the managed code layer and the heap corruption goes away.  I am not sure why this happens.</div><div><br></div><div>You should definitely try and work on Fedora 30 if you can.  Here is some setup for the official build:  <a href="https://gitlab.freedesktop.org/gstreamer/gst-ci/tree/master/docker/fedora" target="_blank">https://gitlab.freedesktop.org/gstreamer/gst-ci/tree/master/docker/fedora</a></div><div><br></div><div>I wonder if this link is related to the official Windows build?  <a href="https://gitlab.freedesktop.org/gstreamer/gst-ci/tree/master/docker/windows" target="_blank">https://gitlab.freedesktop.org/gstreamer/gst-ci/tree/master/docker/windows</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 5, 2019 at 1:36 PM Ben Rush <<a href="mailto:ben@ben-rush.net" target="_blank">ben@ben-rush.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi, thanks, David. I really appreciate your response. That clears up a lot. <br><br>So, this brings me to a straightforward question: is GStreamer generally more stable on Linux than Windows? Or at least, more used? I ask not to be negative but to essentially confirm a belief I have picked up after using it on Windows for a while. Honestly, I have dealt with quite a few more ephemeral issues: random access violations, performance issues, etc. on Windows than I have on Linux. Also, comments about it taking so long to build on Windows, and that there are known bugs that people are potentially not tracking, also makes me think Windows isn't as much the focus. <br><br>None of this is meant to be negative (honest), and I definitely believe major products are using it on Windows, but I'm just curious if there is a basis for these feelings? That perhaps getting it to work as well on Windows as it does on Linux perhaps simply means more work for me. <br><br>Thanks again. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 5, 2019 at 2:43 PM David Ing <<a href="mailto:ding@panopto.com" target="_blank">ding@panopto.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The official Windows binaries are built using this tool:  

<a href="https://gitlab.freedesktop.org/gstreamer/cerbero" target="_blank">https://gitlab.freedesktop.org/gstreamer/cerbero</a><div><br></div><div>The official WIndows binaries are built on a Windows machine, although it is possible to build the mingw binaries from Linux using a cross-compile (through cerbero).  The MSVC build is great because it provides *.pdb files, but not all components can be built using msvc, the remainder are built via mingw.  Unfortunately, building on a WIndows machine takes a really really really long time.  (The cross-compile from Linux is much faster.)</div><div><br></div><div>With Cerbero, the 1.16 branches use a very old version of the mingw toolchain.  The master branch uses a newer version of the mingw toolchain.</div><div><br></div><div>There are a number of known bugs with the Windows version of gstreamer which do not exist on Linux.  (I do not know if anybody is maintaining a list of those bugs.)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 5, 2019 at 11:51 AM Ben Rush <<a href="mailto:ben@ben-rush.net" target="_blank">ben@ben-rush.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I have a desire to build Gstreamer on Windows, more specifically a debug build so that I can track down some crashes that are occurring. Unfortunately, it seems as though this isn't a thing that's well-traveled, or I'm at least getting conflicting information on forums and blog posts about the process. I thought I'd ask on here about the latest state of things since blog posts/forum posts can be depreciated quickly with updates. I'm cool with RTFM, but some sources I'm reading say the manual itself is out of date. <br><br>For example, a couple of blog posts (such as this one: 

<a href="https://cardinalpeak.com/blog/build-gstreamer-on-windows-an-advanced-tutorial/" target="_blank">https://cardinalpeak.com/blog/build-gstreamer-on-windows-an-advanced-tutorial/</a>) that don't appear too old, mention the existing instructions are, and I quote, "woefully out of date" (presumably when specifically targeting Windows) and that the task is "fairly complex". There are Windows builds, and so presumably there is a well-tested method for generating these binaries on Windows. If so, surely there are well-tested steps out there for doing what I want. But if instructions available to me (I'm assuming this blog post meant the official instructions) are out of date, I'd like to keep that in mind as I'm using them. Or if HE is wrong, I'd like to know that. And if the official instructions are NOT out of date, I'm wondering if anyone has had any luck using them to generate any other than release builds? <br><br>Any advice? Pointers? Feedback? Thanks for your time. <br><br><br></div>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></blockquote></div>