<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="https://www.w3.org/2005/Atom" xmlns:sy="https://purl.org/rss/1.0/modules/syndication/" xmlns:dc="https://purl.org/dc/elements/1.1/" xmlns:content="https://purl.org/rss/1.0/modules/content/" xmlns:wfw="https://wellformedweb.org/CommentAPI/" xmlns:slash="https://purl.org/rss/1.0/modules/slash/"
  version="2.0">
  <channel>
    <title>Gilles' Thoughts</title>
    <atom:link
      href="https://docs.microsoft.com/archive/blogs/gillesk/feed.xml"
      rel="self"
      type="application/rss+xml" />
    <link>https://docs.microsoft.com/archive/blogs/gillesk/feed.xml</link>
    <description>A random collection of tidbits</description>
    <lastBuildDate>Wed, 17 Apr 2019 03:39:44 GMT</lastBuildDate>
    <language>en-US</language>
    <sy:updatePeriod>hourly</sy:updatePeriod>
    <sy:updateFrequency>1</sy:updateFrequency>
    <item>
      <title>Building FFmpeg for Windows with HTTPS/TLS support</title>
      <link>https://docs.microsoft.com/archive/blogs/gillesk/building-ffmpeg-for-windows-with-httpstls-support</link>
      <pubDate>Wed, 21 Jun 2017 14:00:00 GMT</pubDate>
      <dc:creator><![CDATA[Gilles Khouzam - MSFT]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.msdn.microsoft.com/gillesk/?p=75</guid>
      <description><![CDATA[I’ve been working and contributing to a few open source projects for the last couple of years. When...]]></description>
      <content:encoded><![CDATA[I’ve been working and contributing to a few open source projects for the last couple of years. When I started, we wanted to focus on pieces that we believed were some of the building blocks that developers would want to use to build Windows apps. The three that I’ve personally focused on were <a target="_blank" href="https://cmake.org">CMake</a>, <a target="_blank" href="https://github.com/microsoft/openssl">OpenSSL</a> and <a target="_blank" href="https://github.com/microsoft/FFmpegInterop">FFmpeg</a>. Recently I was asked to see how to play an https link through FFmpeg. Well, it just happens that in order to playback secure content, FFmpeg leverages OpenSSL. Great, I’ve worked on both projects and they can both be used from a UWP application. This should have been simple, unfortunately not, we had a fairly focused instructions and scripts to build each project, but they were fairly different, required a lot of tools setup and were not very easy to extend. At the same time, VS2017 had been released as well as the Windows 10 Creator’s Update and the work to get all these puzzle pieces aligned properly for our customers began to look like a daunting task. After a bunch of hacking, I was able to get things working; it felt like a house of cards though.

Then last week, I get another request, “Can you please update OpenSSL to the 1.0.2l release? We’re trying to update our drop.” This was coming from the <a target="_blank" href="https://github.com/microsoft/vcpkg">VCPkg</a> team. We had had meetings together a while ago, but had lost touch. I was in for quite a surprise when I synched up with them on what they were doing. They were enabling some of the core open-source projects to built and used in a much more seamless way than what I was used to. When I saw their demo, I was sold. Easy builds without having to manually setup an environment for each project (they take care of that for you), automatic reference of the built projects from your own projects (no need to change include/lib paths), easy dependency resolution and the option to create packages to distribute. As I walked back to my office, I couldn’t help but think about how this could make my life so much easier and from the transitive property of ease, other windows developers. My first project was clear: get FFmpeg with OpenSSL support building in VS2017. I had already spent quite some time trying to get all this working with some very complicated instructions that if I could simplify things, it could only been better for everyone.

I got myself setup and the first hurdle that I found was that VCPkg supported FFmpeg for Desktop but not as a UWP. Challenge accepted. There were instructions, I had done it many times, they were leveraging CMake as their scripting language as well to setup the proper build environment. Overall, these were all things that I was very comfortable with. It didn’t take long, and I had a first build of FFmpeg for UWP built through VCPkg. That was quite encouraging, I did run into some roadblocks but having done this before, I could at least compare the work that we had done before with the current work when running under VCPkg and try to isolate the differences. I spent a little time over the weekend and got my UWP build of FFmpeg completely automated and integrated with VCPkg. Now for the second challenge: Getting it built with OpenSSL support to handle HTTPS/TLS. Thanks to some quite detailed documentation, it was not hard to specify that I wanted FFmpeg to have a dependency on OpenSSL, make a small FFmpeg patch to detect OpenSSL on Windows in this new environment and voila! I’ve got a build of FFmpeg that includes support for secure contents. Now came time for the actual test: does this all work as expected?

I had enabled the VS integration for VCPkg, so I started by taking our <a target="_blank" href="https://github.com/Microsoft/FFmpegInterop">FFmpegInterop</a> project and removed all the customizations necessary to reference FFmpeg (no more extra include paths, no more adding dlls as content). Once everything was cleaned and the project looked like a simple project, I was able to build it, still referencing FFmpeg headers and linking against the libs without having to have the project know anything about FFmpeg (even less OpenSSL). The second modification was to remove the FFmpeg dlls from the actual application that was using FFmpegInterop. Final steps, build, run and open an https link. Everything worked as promised. <strong>Mission accomplished.</strong>
<h3>Trying it out:</h3>
The steps to run this are actually quite simple.
<blockquote>Clone my fork of the vcpkg project (until the code gets upstream)

<code>git clone <a href="https://github.com/khouzam/vcpkg">https://github.com/khouzam/vcpkg</a> -b ffmpeg-openssl</code>

<code>cd vcpkg</code>

<code>bootstrap-vcpkg.bat</code> (to build the VC package manager)

<code>vcpkg integrate install</code> (from an admin command prompt to have Visual Studio integration).

<code>vcpkg install ffmpeg:x86-uwp ffmpeg:x64-uwp ffmpeg:arm-uwp ffmpeg:x86-windows ffmpeg:x64-windows</code> (If you don't have CMake installed, you will be prompted to install it).

You can select which flavors of builds you are looking for by choosing the different architecture or platform combination (uwp for store apps and windows for desktop apps). Notice how OpenSSL is automatically built and referenced when you build FFmpeg. Once completed you will get all the built binaries in your <code>vcpkg\installed</code> with the different architectures.</blockquote>
As you can see, this can be much easier than following some of the manual steps needed to build either OpenSSL or FFmpeg for Windows.]]></content:encoded>
    </item>
    <item>
      <title>Building FFmpeg using WSL</title>
      <link>https://docs.microsoft.com/archive/blogs/gillesk/building-ffmpeg-using-wsl</link>
      <pubDate>Fri, 02 Dec 2016 15:39:00 GMT</pubDate>
      <dc:creator><![CDATA[Gilles Khouzam - MSFT]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.msdn.microsoft.com/gillesk/?p=46</guid>
      <description><![CDATA[Two of the projects that I’m directly involved in are Bash on Windows and FFmpegInterop. For those...]]></description>
      <content:encoded><![CDATA[Two of the projects that I’m directly involved in are <a href="https://github.com/Microsoft/BashOnWindows">Bash on Windows</a> and <a href="https://github.com/Microsoft/FFmpegInterop">FFmpegInterop</a>. For those that don’t know: <strong>Bash On Windows</strong> is a new feature that runs native Linux binaries directly on the new Windows Subsystem for Linux (WSL). <strong>FFmpegInterop</strong> is an open-source project that we’ve created to help developers integrate <a href="https://github.com/FFmpeg/FFmpeg">FFmpeg</a>, a popular open-source video library, with Windows store applications (Windows 10 UWP, Windows 8.1 and Windows Phone 8.1). As part of the process of using FFmpegInterop, building FFmpeg for store applications is required. Building FFmpeg on Windows is not trivial by any means. FFmpeg has many <a href="https://trac.ffmpeg.org/wiki/CompilationGuide">Compilation guides</a> for their different platforms, including cross-compiling for Windows, which can be done from within Linux. For now, we’re going to focus on building the FFmpeg binaries using Visual Studio’s compiler tool-chain.

Since we started working on WSL, getting Windows and WSL to talk to each other and be able to drive one another has been on my mind. Recently we announced our <a href="https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-and-ubuntu-interoperability/">Interop story</a> for WSL, allowing users to launch Windows processes directly from the Linux subsystem and vice-versa. I wanted to see how difficult it would be to build FFmpeg inside Bash, using the new interop, as opposed to having to install msys2 &amp; build FFmpeg in Windows.
<h3>Prerequisites</h3>
To build FFmpeg in Bash on Windows, I install/configure the following:
<ul>
 	<li>Windows 10 64-bit Insider Build 14971, or later (to ensure Bash/Windows interop is available)</li>
 	<li>WSL &amp; Developer Mode were enabled. You can follow these <a href="https://msdn.microsoft.com/en-us/commandline/wsl/install_guide">instructions</a>.</li>
 	<li>Visual Studio 2015 and the Windows 10 SDK. This is the toolchain that we’ll use to build FFmpeg.</li>
        <li>For now the Linux distribution needs to be 16.04 (needed for the new version of realpath). You can use <code>do-release-upgrade</code> on your own to update to 16.04 if you are still running 14.04</li>
</ul>
With all these things setup, I’ll go through the steps to build FFmpeg for Windows 10 UWP applications, leveraging the scripts that we wrote for FFmpegInterop.
<h3>Build Steps</h3>
<ul>
 	<li>Open a Bash console</li>
 	<li>Navigate to the Windows filesystem, where you’ll clone the FFmpeg repo, for now its important to clone the repository using the linux version of git to get the unix line-endings properly set:</li>
</ul>
<code>cd /mnt/c/dev/</code>
<ul>
 	<li>Update the apt-get package index:</li>
</ul>
<code>sudo apt-get update</span></code>
<ul>
 	<li>Install the necessary dev tools in Bash using apt-get (C++ preprocessor, make, the yasm assembler and pkg-config)</li>
</ul>
<code>sudo apt-get install cpp make yasm pkg-config</code>
<ul>
 	<li><span style="color: #000000">Download the gas-preprocessor for ARM and copy it to /usr/bin so that it is in your path:</span></li>
</ul>
<code>wget &#x2D;-no-check-certificate <a href="https://raw.githubusercontent.com/FFmpeg/gas-preprocessor/master/gas-preprocessor.pl">https://raw.githubusercontent.com/FFmpeg/gas-preprocessor/master/gas-preprocessor.pl</a> &amp;&amp; chmod +x gas-preprocessor.pl &amp;&amp; sudo mv gas-preprocessor.pl /usr/bin</code>
<ul>
 	<li>Clone the FFmpegInterop repo using the gillesk/wsl branch, including the FFmpeg submodule (this could be done on Windows or Linux side):</li>
</ul>
<code>git clone <a href="https://github.com/Microsoft/FFmpegInterop">https://github.com/Microsoft/FFmpegInterop</a> -b gillesk/wsl &#x2D;-recursive</code>
<ul>
 	<li>Apply the FFmpeg patch (until we can try to push it upstream to FFmpeg)</li>
</ul>
<code>cd FFmpegInterop/FFmpeg</code>

<code>git am ../0001-Updating-scripts-to-run-under-WSL.patch</code>
<ul>
 	<li><span style="color: #000000">From a new Windows command prompt, navigate to the project folder and run the BuildFFmpeg.bat script, passing the WSL parameter</span></li>
</ul>
<code>C:</code>

<code>cd \dev\FFmpegInterop</code>

<code>BuildFFmpeg.bat WSL win10 x86 </code>
<ul>
 	<li><span style="color: #000000">You should now get a proper build in the FFmpeg/Output/… folder.</span></li>
</ul>
<h3><span style="color: #000000">Things that had to change to make this possible</span></h3>
<span style="color: #000000">While most things work transparently, a few changes to the build scripts for FFmpeg needed to be made to enable the interop. The main set of issues I encountered are centered around handling line endings between the two systems.</span>
<ol>
 	<li><a><span style="color: #000000">Changed the configure script for FFmpeg (and associated shell scripts) to call tools including their extensions (cl.exe instead of cl for example). This is necessary, because WSL can automatically launch Windows processes from the Linux side but only if the process is in the path and includes the full name. Linux doesn’t automatically append .exe and such to invoke a file. </span></a></li>
 	<li><span style="color: #000000">Create a patch for FFmpeg and add it to the FFmpegInterop repo. (Until we can get them integrated in FFmpeg).</span></li>
 	<li><span style="color: #000000">Changed the configure script to clean some \r that can get appended when running windows tools through the scripts. </span></li>
 	<li><span style="color: #000000">Updated the FFmpegInterop repo to add a .gitattributes file, so that the FFmpegConfig.sh script using LF (not necessary if cloned or checked out through Linux). </span></li>
 	<li><span style="color: #000000">Updated the FFmpegInterop build script to have a new WSL optional parameter that builds using WSL instead of MSYS2.</span></li>
 	<li><span style="color: #000000">Removed the code to make a symbolic link to the FFmpeg sources and just access the sources through a relative path because at the moment symbolic links don’t cross the subsystem boundary.</span></li>
</ol>
&nbsp;
<h3>Comparing both systems</h3>
<span style="color: #000000">Both systems do achieve the same results, and the changes to enable WSL for FFmpeg are pretty minor, and work for both Msys and WSL, so hopefully they can get integrated upstream fairly easily. </span>

<span style="color: #000000">I found the configuration of the environment easier from the WSL side, using apt-get to install the prerequisites as well as not having to worry about which version of an executable gets invoked (link vs link.exe for example) since we are explicitly adding the extension in our scripts when invoking Windows executables. Getting the proper line endings though has been difficult. Linux shell scripts don’t run properly when they have CR in them; running Git from the Linux side helps to make sure that text files have the proper line endings.</span>

<span style="color: #000000">But one huge advantage that I was not expecting was in terms of performance: Building x86, x64 and ARM Windows 10 versions of FFmpeg is almost twice as fast under WSL than it is in Msys. On my HP Z440, I build all three in just over 20 minutes while Msys takes just over 37 minutes. My Surface Pro 3 results are also showing similar gains.</span>

<span style="color: #000000">Hopefully more projects can be adapted for WSL to help bridge the gap between Linux and Windows.</span>]]></content:encoded>
    </item>
    <item>
      <title>Bringing Multicast to Silverlight</title>
      <link>https://docs.microsoft.com/archive/blogs/gillesk/bringing-multicast-to-silverlight</link>
      <pubDate>Tue, 12 May 2009 20:13:41 GMT</pubDate>
      <dc:creator><![CDATA[Gilles Khouzam - MSFT]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.msdn.microsoft.com/gillesk/2009/05/12/bringing-multicast-to-silverlight/</guid>
      <description><![CDATA[Qumu and Microsoft just annouced that Qumu will offer a Silverlight plugin that will receive...]]></description>
      <content:encoded><![CDATA[<p>Qumu and Microsoft just annouced that Qumu will offer a Silverlight plugin that will receive multicast streams (<a href="https://www.qumu.com/newsroom/news-releases/2009/silverlightplugin.htm">Qumu Press Release</a>). It’s great because this will allow enterprises to broadcast internal events much more efficiently. I’ll admit that supporting directly in Silverlight would have been nicer, but at least we’ve got a viable solution now. It’s been very frustrating to have internal events being streamed in WMP and not accessible to Silverlight, finally this will change. The other nice thing, is that Mac users will also be able to use the solution, afaik, this is the first release of a multicast client for Mac in a very long time.</p>  <p>Personally, I’m still very excited by the fact that Silverlight is open enough to enable people to extend our functionality in such a way.</p>  <p>If you’re interested the code will be available on <a title="https://projectstarlight.codeplex.com/" href="https://projectstarlight.codeplex.com/">https://projectstarlight.codeplex.com/</a><a href="https://projectstarlight.codeplex.com/"></a></p>]]></content:encoded>
    </item>
    <item>
      <title>Playing back Wave files in Silverlight</title>
      <link>https://docs.microsoft.com/archive/blogs/gillesk/playing-back-wave-files-in-silverlight</link>
      <pubDate>Mon, 23 Mar 2009 14:32:00 GMT</pubDate>
      <dc:creator><![CDATA[Gilles Khouzam - MSFT]]></dc:creator>
      <guid
        isPermaLink="false">https://blogs.msdn.microsoft.com/gillesk/2009/03/23/playing-back-wave-files-in-silverlight/</guid>
      <description><![CDATA[I’ve been working on Silverlight for a couple of years now, and finally decided to start talking...]]></description>
      <content:encoded><![CDATA[<p>I’ve been working on Silverlight for a couple of years now, and finally decided to start talking about it in my blog. With the recent beta, we’ve added raw A/V support to Silverlight 3, and that means not only that people will be able to write their own decoders for Silverlight, but also that they can now play back PCM audio through managed code. The easiest way to get PCM data is simply to use a Wave file. Wave files are a container format for multiple audio encodings, so not all files will play back in Silverlight, but the PCM encoded ones will. To help out, I’ve published a sample MediaStreamSource implementation on Code Gallery (<a href="https://code.msdn.microsoft.com/wavmss" mce_href="https://code.msdn.microsoft.com/rawmss">https://code.msdn.microsoft.com/wavmss</a>).</p>  <p>The easiest way to try out the code is to open a local wave file from your drive using the OpenFileDialog (C:\Windows\Media has a bunch of little sound bites).</p>  <pre class="csharpcode"><span class="kwrd">private</span> <span class="kwrd">void</span> Button_Click(<span class="kwrd">object</span> sender, RoutedEventArgs e) 
{
    OpenFileDialog ofd = <span class="kwrd">new</span> OpenFileDialog(); 

    <span class="kwrd">if</span> (ofd.ShowDialog().Value)
    {
        Stream s = ofd.File.OpenRead();
        WaveMediaStreamSource wavMss = <span class="kwrd">new</span> WaveMediaStreamSource(s);
        <span class="kwrd">try</span>
        {
            me.SetSource(wavMss);
        }
        <span class="kwrd">catch</span> (InvalidOperationException)
        {
            <span class="rem">// This file is not valid</span>
        }
    }
} </pre>
<style type="text/css">
.csharpcode, .csharpcode pre
{
	font-size: small;
	color: black;
	font-family: consolas, "Courier New", courier, monospace;
	background-color: #ffffff;
	/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt 
{
	background-color: #f4f4f4;
	width: 100%;
	margin: 0em;
}
.csharpcode .lnum { color: #606060; }</style>

<p>This snippet will play the wave file right away. Remember that to get the FileOpenDialog, you need to hook the handler to a user initiated action. An easy way for this, is to put a MediaElement and a button on a page.</p>

<pre class="csharpcode"><span class="kwrd">&lt;</span><span class="html">UserControl</span> <span class="attr">x:Class</span><span class="kwrd">=&quot;SampleWave.MainPage&quot;</span>
    <span class="attr">xmlns</span><span class="kwrd">=&quot;https://schemas.microsoft.com/winfx/2006/xaml/presentation&quot;</span>
    <span class="attr">xmlns:x</span><span class="kwrd">=&quot;https://schemas.microsoft.com/winfx/2006/xaml&quot;</span>
    <span class="attr">Width</span><span class="kwrd">=&quot;400&quot;</span> <span class="attr">Height</span><span class="kwrd">=&quot;300&quot;</span><span class="kwrd">&gt;</span>
    <span class="kwrd">&lt;</span><span class="html">Grid</span> <span class="attr">x:Name</span><span class="kwrd">=&quot;LayoutRoot&quot;</span> <span class="attr">Background</span><span class="kwrd">=&quot;White&quot;</span><span class="kwrd">&gt;</span>
        <span class="kwrd">&lt;</span><span class="html">MediaElement</span> <span class="attr">Name</span><span class="kwrd">=&quot;me&quot;</span><span class="kwrd">/&gt;</span>
        <span class="kwrd">&lt;</span><span class="html">Button</span> <span class="attr">Name</span><span class="kwrd">=&quot;b&quot;</span> <span class="attr">Width</span><span class="kwrd">=&quot;200&quot;</span> <span class="attr">Height</span><span class="kwrd">=&quot;20&quot;</span> <span class="attr">Content</span><span class="kwrd">=&quot;Open&quot;</span> <span class="attr">Click</span><span class="kwrd">=&quot;Button_Click&quot;</span><span class="kwrd">/&gt;</span>
    <span class="kwrd">&lt;/</span><span class="html">Grid</span><span class="kwrd">&gt;</span>
<span class="kwrd">&lt;/</span><span class="html">UserControl</span><span class="kwrd">&gt;</span></pre>
<style type="text/css">
.csharpcode, .csharpcode pre
{
	font-size: small;
	color: black;
	font-family: consolas, "Courier New", courier, monospace;
	background-color: #ffffff;
	/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt 
{
	background-color: #f4f4f4;
	width: 100%;
	margin: 0em;
}
.csharpcode .lnum { color: #606060; }</style>

<p>That’s it, you can now play wave files.</p>]]></content:encoded>
    </item>
  </channel>
</rss>