ASF2VC1 v1.2

Introduction
============
This small command line utility losslessly converts Windows Media WMV9 Advanced Profile (i.e. WVC1 "*.wmv" files) into non-Microsoft-specific VC-1 "encapsulated elementary" bitstream files (i.e. "*.vc1" files). For more information on creating these WMV files, including an explanation of what they are, the necessary requirements, and a variety of tools that can be used, I highly recommend the following link - a so-called "sticky-thread" that is part of an "doom9" advanced video forum.

http://forum.doom9.org/showthread.php?t=112634

The resulting files should be suitable any number of purposes, e.g. as input material for Blu-ray and HD DVD authoring applications. Although I do not currently have the resources to perform test authoring of such DVD's, the resulting bitstreams have gone thru a fair amount of compliancy testing (more on that below). The files are compliant with the VC-1 standard specification (SMPTE 421M-2006) in general, and in particular with Annexes "E" and "G" of said document. Those annexes define the properties of a "conformant bitstream" of the type we are discussing.

This document will be brief, as I'd like to get the application "out there" as soon as possible to speed up the process of gathering feedback on any bugs or changes that need to be made to, or enhancements that would increase its usability. Furthermore, the app is extremely simple to use to begin with, and as such does not require much explanation. And to the extent that it does, simply typing "asf2vc1 -h" at the command line will display the long version of the built in usage information, which includes about all there is to know.

System Requirements
===================
This application has NO system requirements' to speak of, from either hardware or software perspective, though it currently doesn't run on Win9x, if anyone cares (due to Unicode issues). Other than that, if your PC can read and write files, then the app should run fine. It consists of a single executable file, written from scratch. No DirectShow, no codecs, no SDK's, other apps or anything else is needed. It was even "statically" linked so it shouldn't depend on any particular DLL versions or anything like that. In fact, your PC doesn't even need the ability to play video, much less encode it. If you can obtain the .wmv file to want to convert, you should be able to convert it.

==> Note to the "non-computer savvy": This is a console application, though aka "command line interface" (CLI). You do need to bring up a command window ("DOS prompt") and type the name of this app "ASF2VC1" followed by the names of the files to be converted. Use full paths for the files(s) and/or the app if they are not in the current directory. If you don't understand that much, you'll have to do educate yourself a bit more research before using this ;). The app has been tested on Win2K, XP and Vista.


How To Use It
=============

-- General --

As the built-in usage message explains, the basic usage is

ASF2VC1 <filename.wmv> <filename.vc1>

which will read the first file and create the second. Additionally, as a convenience, it can be used as an information utility to provide limited info on either a .wmv or a .vc1 file by using a single filename of either type. This feature is not comprehensive, but was quickly added using any code that already needed to be there anyway. As the help mentions, if you may be able to gain even more information by performing a "fake" conversion using "nul" or "nul" as the output filename and setting the "verbose" 2 (the default) or even to "3" (for frame-by-frame info). "nul" is simply a CLI construct that acts as a phony filename (aka "bit-bucket"), so the app will go thru the full conversion, with all the info displayed, yet not waste room or time by writing an actual output file

-- Flags - Verbosity --

Again, as explained on the help screen, there are four "verbosity" levels depending on how much technical stuff you want to see as the conversion takes place. It is important to note that these flags have NO effect on the output file created.

"0" and "1" are for people who don't want to see all that stuff; "2", the default, displays everything it does bit when it gets to the actual frame-by-frame extraction it displays the "per-frame" info in a compact table-like format. If you really want it, "3" will display everything "2" does as well as an individual line for each frame converted. The line includes the frame number, time, and type, size in bytes and whether or not it's a keyframe.

Note the frame numbers are 1-based (the first frame is "1" - sometimes the first frame is called '0"). And the times are zero-based, which is quite normal, although Microsoft's internal conversion utility adds the "pre-buffer" time to every frame (e.g. frame #1 might display t=5.000 seconds and then the numbers go up from there).

-- Flags - Other --

There are a number of useful flags which *could* be there but are not yet implemented in this version. Most are relatively easy, but I wanted to get this release out now and I'll add them for the next release. These would include flags which would either to set (when not known) and/or manually override a value the app would have used for the various basic parameters - e.g. a "set/force framerate" flag or "set/force PAR value flag".

As it is, the three existing flags are NOT particularly useful and none are really recommended. All *remove* info that would otherwise be inserted. If you're wondering why they're there - and in particular why I put them there now instead f the others - it all had to do with testing, and is (more on that later).

But very quickly, the "-nfrm" and "-npar" flags (see help screen) allow you to generate files with framerate and or PAR *not* included, respectively, where it otherwise would (or might) be. The first one, in particular, is really not recommended - the authoring program or player reading the file will have no idea what the frame rate is. These files are legal, but much less useful.

The third, "-nseq", will include a VC-1 "sequence header" before the first frame only, subsequent keyframes will be preceded by a VC-1 "entry point" header only. This is legal, and will make the file a *tiny* bit shorter, and may have no negative effect. Nonetheless, many files always include the full pair before each keyframe. Among other advantages, the VC-1, with that in place, the resulting elementary file is such that it could be split, truncated, edited or concatenated with something as simple as a hex editor, and the resulting files would be valid. As I say, I recommend against using that flag as well, and once again this is the default.

-- Summary --

To summarize, it's suggested you simply use the simplest command line
ASF2VC1 <filename.wmv> <filename.vc1>

Or perhaps something like
ASF2VC1 -v3 <filename.wmv> <filename.vc1>

But beyond that there's not much reason to fool with flags in this release.


Conformance
===========
OK, here's a nice part. Besides conforming to the spec by design, I've done two very important sets of tests:

1. I was lucky enough to get my hands on a collection of nine widely varying WVC1 .wmv files, and their corresponding equivalent VC-1 elementary stream files, as created by Microsoft, using their own internal utilities. That's the reason for the odd command line flags previously mentioned. The Microsoft VC-1 were technically VC-1 "conformant" streams, but quite "stripped down". But when I run the following command

ASF2VC1 -nfrm -nseq -npar <ms-file.wmv> <ms-file.vc1>

All nine results were *bit for bit* identical. I consider this a very encouraging result.

2. I also have managed to compile a working version of the SMPTE 421M reference decoder. The encoder, which is slow as molasses, does do a huge number of validity checks - so much so that SMPTE even implies (or even states? - I forget) - in so many words - that "if it makes it thru the reference decoder with no errors or warnings, the file is complaint. All nine files passed that test, too.

3. For good measure, I managed to actually play the output of the decoder, despite its large and awkward "raw" YUV format. The resulting movie clips all displayed as expected.


A Few Technical Details
=======================
Conversion performed by this version of ASF2VC1 include support for both progressive and interlaced files, including support for all thirteen or so frame types & subtype combinations as summarized at the end of a verbosity "-v3" level conversion.

It also includes support for a number of advanced WMV/VC-1 features including non-square PAR values, a "coded size" that differs from "display size", and multiple video streams.

Regarding that last point, another good future option would be "-force stream = x". The current code will, however, in a multi-stream file, search for the "high bandwidth" stream and encode that one, ignoring the others. I added that feature when I found out through personal experience that, at least in my opinion, it's multi-stream *accidentally*, at least when using the WME9 GUI encoder. There may be several bitrate tabs on "Custom Encoding Settings" dialog - I thought they represented a choice, whereas in actuality the file contains a stream for each tab shown.

And if that wasn't a problem enough already, it's compounded by something very unusual about the ASF file structure. When parsing the file, the only "Stream Properties Object" that is apparent is for the *low* bandwidth video is apparent - the "Stream Properties Object" for the "good" stream is, apparently intentionally, "hidden" in a completely unexpected place. Indeed, one and only the previous beta version of this app, ASV2VCF v1.0, would always encode the 'wrong" stream. Anyway, that's all corrected now. At verbosity level "v2" or above, the app will inform you what stream(s) it found and what it will be encoding.

I could go on about a lot more technical stuff, but his document is already much longer than I planned. I'll just finish up with two additional comments concerning my future plans.

- I do plan to release the source code, along with an explanation. It was coded using an "table driven" algorithm I devised just for this purpose. The table is used for both reading and writing the various "variable bit-length" constructs which comprise the VC-1 headers. That way I can easily read back whatever fields may or may not be present, optionally add /modify or remove table entries in "normal" form integer form, and then "run the table backwards" to construct a new variable-bit length sequence. I think some programmers out there may find the technique interesting.

- If anyone's going to ask about a Linux port- I don't know if I'll do it myself or not. But given that it's a CLI app, the conversion should be quite trivial - once I post the source code it could probably be converted quite easily.

The current version was compiled using MS VC 8, and will also compile under MS VC 6 once I straighten out a few Unicode related flags.

Contact
=======
Please direct all comments, bugs, suggestions, etc to steve (at) headbands.com, and make sure to at least include the name "ASF2VC1" somewhere in the subject line. I will update my spam filter to automatically allow any any such emails.

Steve G
27 May 27, 2007