A Windows Version, Please
A friend wanted to use my ffmpeg
video packaging script. But there was a catch: he needed it to
run on Windows. As a bash script, it runs seamlessly on
Linux and MacOS, Windows not so mch.
The immediate solutions that came to mind weren't very helpful. I
could re-write the script to be cloud based, but that would be
terrifically inefficient in terms of both my time and complexity. I
could have have my friend install a Unix environment on his Windows
computer, but that seemed overkill for one script.
I could re-write my script in PHP and have my buddy install XAMPP. But
again, that felt like swatting a fly with a sledge hammer.
The exercise I was going through was a familiar one. As a
programmer, I'd been given an issue and I was making my way through
the 5 stages of grief. Denial: nobody can expect me to make a
Windows version of this script. Anger: why can't Windows be Linux!
Bargaining: OK, you can have this script, but only if you turn your
Windows box into a Linux box. Depression: ugh, Windows. And
finally, acceptance: OK, so how would one do this on Windows?
Let's Do This!
I had an idea: I'd previously experimented
PowerShell. And by experimented, I mean I launched the program, was
excited to see it did tab completion and then quickly tired of using
it. I'm sure it was step up from the standard DOS box, but it felt
far inferior to the bash environment Cygwin provided. Still,
PowerShell was a shell, so may be it had a scripting language I
could use?
Finding sample PowerShell scripts was easy. At
first I was overwhelmed: PowerShell was considerably more verbose
than bash. But the ingredients for shell scripting were all
there. After cursing Microsoft, it looked like PowerShell may be just
the solution I was looking for.
Fast forward a couple of days, and I now have a version of my video
packaging script that runs on Windows; no massive install of support
tools required. Grab it here. You can run
it by right mouse clicking on package.ps1 selecting
Run with PowerShell. You can also launch the script within
PowerShell using command line arguments. For example:
> .\package.ps1 -Source c:\Users\ben\Downloads\bigvid.mp4 `
-Config c:\Users\ben\Documents\blog\video-settings.ini
The Case for PowerShell
Here's a number of features of PowerShell that have left me more
than a little impressed.
PowerShell let's me trivially launch a file picker, so that I can
allow users to select the video and configuration file in a
graphical way. It's also easy to confirm the files are valid and
kick up a graphical alert box and if this isn't the case. In other
words, PowerShell lets me do Windowsy things easily.
# Let users pick a file
function Prompt-File {
param($Title, $Filter)
$FileBrowser = New-Object System.Windows.Forms.OpenFileDialog -Property @{
InitialDirectory = [Environment]::GetFolderPath('MyDocuments')
Title = $Title
Filter = $Filter
}
$null = $FileBrowser.ShowDialog()
Return $FileBrowser.FileName
}
# Prompt for the video and config files
$Source = Prompt-File -Title "Choose Video" -Filter 'MP4 (*.mp4)|*.mp4|QuickTime (*.mov)|*.mov|AVI (*.avi)|*.avi'
$Config = Prompt-File -Title "Choose Settings File" -Filter 'INI File (*.ini)|*.ini|Text File (*.txt)|*.txt'
PowerShell doesn't natively support parsing ini files, but writing
the code to do so was straightforward. I was able to adapt code on
the web such that reading an ini file took in an existing set of
values.
$settings = @{}
$settings = Parse-IniFile -File $PSScriptRoot\defaults.ini -Init $settings
$settings = Parse-IniFile -File $Config -Init $settings
Here I'm setting the variable $settings to an empty
hashtable. I'm then filling the hashtable with the value of
defaults.ini and then overriding these values with the user selected config file. This is similar to the variable
overriding I did in the Unix
version of the script, though arguably it's cleaner.
I was able to move my custom code to separate files in
lib directory, thereby keeping the main script readable.
I'm impressed how PowerShell natively handles named parameters. Not
only can I define functions with named parameters, but I was able to
have the script itself trivially take in optional parameters. At the
top of package.ps1, I have:
param($Source, $Config, $SkipFcsGeneration)
I then check to see if -Source or -Config was passed in. If either are missing,
Prompt-File is invoked.
if(-not $Source -Or (-not $(Test-Path $Source))) {
$Source = Prompt-File -Title "Choose Video" -Filter 'MP4 (*.mp4)|*.mp4|QuickTime (*.mov)|*.mov|AVI (*.avi)|*.avi'
}
if(-not $Config -Or (-not $(Test-Path $Config))) {
$Config = Prompt-File -Title "Choose Settings File" -Filter 'INI File (*.ini)|*.ini|Text File (*.txt)|*.txt'
}
These named parameters let me treat my script as a command line
tool, and let's a typical Windows user think of it as graphical app.
I also improved the packaged video file itself. I added support for playing
audio over the 'pre' title screen. The script uses
ffprobe -show_streams to figure out the length of the audio clip
and arranges for the title screen to be shown for this duration. PowerShell let me trivially kick off ffprobe and process its
output, just like I would do in a bash environment.
Working with the audio stream forced me to understand how ffmpeg's
complex filters worked when both video and audio streams are being
manipulated. My Aha Moment came when I realized that you filter audio and video
separately and that ffmpeg will piece them together. Essentially, I have one concat
expression to join all the video streams and one to join the audio
streams, and ffmpeg does the right thing to combine the audio and
video at the end.
A Happy Ending
I finished this little project with not just a video
packaging script that works on Windows, but with a fresh
perspective on Windows scripting. What PowerShell lacks in tradition
and terseness, it more than makes up for in capability and
completeness. In short, PowerShell isn't an attempt to implement
bash on Winows; it's a fresh and modern take on scripting that really
delivers.
Check out my video packaging code over at github.
