Did you think I fell off the face of the earth?  No, I’ve just been busy moving Bat Converter up to its Alpha release.

Bat Converter is a Windows-only tool I developed to automate a process in which I regularly engage – converting video formats.  The three options are to set it up to (1) convert TV Recordings to mpeg, (2) convert any other video to a format compatible with the iPad or new iPhone as well has many Android devices (like my Droid Incredile), and (3) to convert to an iPad version, an iPhone 3GS version, an OGV version, and a flash video.   That’s right, Option 3 generates four output files for every one that you feed it.  Conversions occur in a minimized console.  When they are complete the destination folder will open with all your newly converted videos.  Other than the .wtv to .dvr-ms conversion, there is no progress window.  Converting videos is a long process.  I like to run my program and go to bed.  In the morning, there is my window open with all those files ready to do my bidding.

Specifically, I record TV using the Media Center in Windows 7, but I want to be able to watch it on my wife’s iPad, one of the few XP notebooks, or the Tivo HD.  That means the Windows TV (wtv) container has to be changed.  (Bat Converter uses the Windows 7 WTVConverter utility to generate the episode in the dvr-ms format.)  The original and this copy are left in the original folder.  The dvr-ms episode retains all of the original metadata and quality.  The dvr-ms episode is then converted to mpeg at the same quality level but without the metadata.  (Somebody please tell me how to retain the metadata.)  The conversion from dvr-ms to mpeg is done using an older version of FFmpeg.  The newer releases seem to have this ability broken.  By putting this mpeg version in the My Tivo Recordings folder, I can watch it on my Tivo in the other room (or change the name to the right format and watch it on XBMC).

By default, I place the mpeg version in the ‘Videos2Convert’ folder.   Along with most other formats (and more to come in future releases), any videos in this folder can be converted using option 2 or 3.  This is accomplished using the newer version of FFmpeg.  This software uses code of FFmpeg licensed under the LGPLv2.1. This software uses libraries from the FFmpeg project under the LGPLv2.1.  Since I have included the libx264 libraries, be advised that they cannot be used for any commercial purpose and are subject to the restrictions of their copyrights.

We like to have some shows on the iPad in case we get rained in at camp.  Using Option 2 and changing the output folder to the ‘Automatically Add to iTunes’ directory, makes those videos available the next time I sync the iPad with iTunes (find them under ‘Movies’).  I also use option 2 to convert videos family members have recorded in the myriad of current formats used by today’s cameras. Less often, I’ll use it to convert videos I downloaded from the internet.

The third option is handy for those of us who want to post videos for HTML5 compatible browsers.  It generates the three top formats.  By using those three formats with the <video> tag, the video can be used with the latest version of all the major browsers.  A bonus flash video is also generated just in case you want to degenerate to flash for users confined to older non-HTML5-compliant browsers.

Bat Converter can be placed anywhere on your computer.  You could even make three copies and configure one for each option.  Every time you run setup it reverts to the original default path configuration, though, so make sure the paths still point to the right place before you click one of the ‘Save” options.

A further note.   The graphical user interface (GUI) for configuration is on the MS Internet Explorer/Windows Scripting Host platform so if you don’t have those you’ll have to change the ‘batconverter-configuration.dat’ folder manually and skip running ‘setup.bat.’  I tested Bat Converter on four computers and the GUI did not function fully on one of them. I have one more project I want to finish using batch files, VBScript, and HTA.  Then, I’ll start working on learning a language that is less platform specific.  I love Linux, but I had to start somewhere and since I use Windows as my DVR . . .

This is an alpha release.  Your comments and feedback can help to make further versions better.  If anyone at FFmpeg or MPEG LA has a problem with how I’m distributing, I am happy to change or pull my product.  If you would like to thank me for building this for you, please feel free to make a donation to Habitat for Humanity ($3 suggested).

And now, without further ado, I give you the download link:

BatConverter.zip

UPDATE:  Per the comment below,There was a glitch in the initial release by which the ‘Save and Run’ button during setup only saved. That button has been removed. Please save the setup and then just run BatConverter.cmd until you need to change the setup. Then just run ‘Setup.bat’ again to make and save your changes.

BatConverter-alpha01.zip

1 – Produce a Video
The preferred format is an mp4 container with the AVC/H.264 video codec (mpg with the mpeg2 codec is second choice) and MP3 or AAC (needed for surround sound) audio codec.  This minimizes losses in the video conversions that will be done by either your video host or yourself.  The preferred resolution is 1920×1080 (1080p) or 1280×720, but not greater than the resolution of the raw footage used to produce the video.  Apple TV can display H.264 video, up to 5mbps, 1280×720, 24 fps, Progressive Main Profile. Apple TV supports AAC-LC audio up to 320 Kbps. The gating factors for video are bit rate and frame rate.

We’ll go into frame rates below, but minimize changes from the frame rate of your source video.  There is no point (in fact there are losses) in increasing the fps from 15 to 30 if the original footage was at 15 fps.  While the bitrate for audio can go as high as 48 kHz, YouTube prefers 44.1 kHz.

iTunes only accepts .m4a, .mp3, .mov, .mp4, .m4v, and .pdf so the fewer steps to mp4 the better.  The iPod/iPhone/iTouch support 640×480 while the Apple TV supports 1280×720.

2A – With An External Video Host
This means that you show your YouTube, Vimeo, blip.tv, or metacafe video embedded on your website.  It is easy and low risk.  Although typically there will be some host branding, the players tend to be quite attractive.  It also opens your show up to a broader audience that may be searching for videos specifically on those sites.

Upload the video from step one to the video host (YouTube, Vimeo, Blip.TV)

Now, we’re going to juggle two browser windows.  I find this easier (alt-tab) than switching between tabs.  In a new window create a new blog post.

In the old window, customize and copy the embed code from the video host.  Be sure the width of the video will fit comfortably in the space available in your blog.

Alt-tab back to the new window and paste the embed code into the blog post.

If you can access your mp4 or m4v source file on the host site copy the link to that file.  We’ll refer to this as the source video URL.  YouTube has a button to download your mp4 but does not provide a URL.  (It can be had using a tool like Video DownloadHelper but that is beyond the scope of this post.)  blip.tv does provide a link to the mp4 file.

If you can’t access your source file url on the host site upload the file to your blog’s media library.  At the WordPress dashboard go to Media – Add Media to upload the file.

Below your embed code create a hyperlink to download the source video file using its url.  Save the draft.  This generates an enclosure for the source code in the hyperlink.  The enclosure has the URL of the file that the RSS feed passes on to iTunes and other feed readers.  Your audience also has the option to download the file for later use or viewing on an alternative platform.

2B – Self Hosting
Self hosting means that you will control where your files are stored and how they are presented.  After you have produced your video, upload it to your server.  (Wait till after, because it is really hard to upload a video that doesn’t exist, right?)  Upload the file to your blog’s media library.  At the WordPress dashboard go to Media – Add Media to upload the file.

Next go to Media in the dashboard to open the media library.  Select your new video and click ‘edit’.  Copy the link to that file.

When editing one’s post, one can simply scroll down to the custom fields, select enclosure as the custom field name, and paste the URL as the custom field value.  Click the ‘Update’ button.  In this way there is no direct link in the post but iTunes will still provide the source video to subscribers.

3 – Publish

When you post your blog, your RSS2 feed will now include the media in the enclosure.  The blog title will be the podcast title in iTunes.  The video title will be the title of the specific episode.  iTunes captures a screen from the first frame of the video and uses that as a thumbnail.  The blog description will be the podcast description.  The blog post text will be the episode description.

iTunes appears to handle only the first enclosure if there is more than one enclosure per post (to provide both an iPod and HD version, for example).  My intention is to put the iPod version as the first enclosure so that iTunes subscribers can sync the show to their iPods.  blip.tv appears to maintain my 1280×720 resolution (a limitation of my source video) so subscribers who go to the web site can see it in HD.

I don’t know if I can add the podcast image and other metadata  after I register with iTunes or will need to use a plug-in in advance.  Their guidelines only state that one can manually set the language, category, and whether or not the content is explicit.  If not, the image can be added using the Podcast Channels plug-in in WordPress.  The podPress plug-in doesn’t seem to offer additional functionality to Podcast Channels.

To see how your feed looks in iTunes, go to the Advanced menu and select Add Podcast Feed and paste in your feed URL.  If all is well, your podcast should appear in your library.  If not you may want to visit Apple’s itunes specs.

4 – Tweak It
There is little uniformity in the way that your audience receives your video.  Some will watch on a Zune others on an iTouch.  Some will watch it in their browsers others will subscribe through iTunes.  Some will be on a Mac using Safari and others on a PC using Internet Explorer.  Some users have flash enabled and others don’t.  Plus the very language we use, HTML, to create our blog or website is changing.

Let’s assume that our mission is to reach the broadest audience we can as beautifully as we can.  That means that we will need at least four versions of every video.

• Our HD source video (see Step 1).  This is optimal for YouTube and other HD hosts.  It will also allow HD viewing for Macs, Apple TV, and viewers using the Chrome browser without flash.  Those on PCs without flash can download this for HD viewing.  I use the Apple TV upper limit described above.  Apple TV may only be a small part of the audience, but very few viewers of a vodcast will use a screen larger than 32″ so who will see the difference?  Besides that, it is as good as my camera video anyway.

• For the iPod-iPad-iPhone-iTouch audience, as well as SD for Macs, Apple TV, and viewers using the Chrome browser without flash:  The mp4 container with an AVC/H.264 video codec and mp3 or AAC audio codec with a bitrate up to 1500 kbps, a resolution of 640×480, and max frame rate of 30 frames per second.  This is the one that goes in our post’s first enclosure.

• For the flash-capable browser set, we’ll need the flv container.  One may even want an HD and an SD flash video option.  SD is better for bandwidth and HD is prettier when bandwidth is not an issue for your viewer.  Maybe I would go with HD if I could only choose one because most folks have high speed connections.  On the other hand people aren’t very patient about waiting for their video to load.  I think I’ll stick with 720×480.

• For the non-flash users who have Firefox and Opera browsers, we need the ogv container with the Theora video codec and Vorbis audio codec.  I wish all browsers supported Ogg because it is open source and open format with none of the H.264 licensing issues.  I also wish for world peace.

It probably goes without saying but generate each of those files directly from the HD source video, not from one of the other formats, to minimize quality losses.

This raises the issue of how to present these choices.  The four videos above fall into two categories, flash and HTML5 (non-flash).  When someone goes to view your vlog, you want them to see your video, not have to hunt for it.  This can be done by starting with the HTML5 video, which I believe is clearly the wave of the future, and degrading to a flash player.  Or it could be done by starting with the flash player, in wide use today, and degrading to the HTML5 video.  Since today is today, I have opted to default to flash and degrade to HTML5.  Also, HTML5 does not inherently include the ability to bring the video to full screen, something I like about flash.

If you are not hosting your own video, you will place your SD mp4 in the first enclosure as discussed above.  It must, therefore, be the first of any hyperlinks.  Remember iTunes only grabs the first enclosure so it should be the one folks can sync with their handhelds.  But also provide links to the other formats to offer maximum flexibility.  The biggest audience goes straight to the flash player.  Everyone else is only one click away from viewing the video.

Now, here is the special advantage of hosting your own video.  Normally, within your java script there is a link to get a flash player that only appears if the viewer does not have access to flash.  Simply replace that sentence and its hyperlink with links to the other videos.  Now, instead of an error message to the non-flashers, links magically appear allowing them to watch the video in one click.  Check out my post on this for the details.  That post also shows how to put a poster of the video behind the links so that your post page still has visual appeal.  It means that the default flashers just click on the play button and the others just click on their appropriate link.  Easy for everybody.

Well, this is the easy part. Being creative? That’s the challenge. Feel free to share links to your vlogs in the comments.

Distributing a video product can be very simple. I just shoot a video with my iPhone. Touch the share button. Touch the ‘Send to YouTube’ button and I’m done.

But if one wishes to produce a regular video program or include video elements in one’s web page or blog then distribute it to the general public things start to get a little more tricky. My wife has a Droid Eris which runs on Android. You may have an old version of Internet Explorer. (Please tell me you don’t.) Some of you have Macs which choke on about 75% of the web’s videos because they are in Flash. On top of everything else, like the iPhone, the new iPad won’t be able to handle Flash at all. We could choose to curse the darkness (you fill in who you would blame), but it is dark so we need to light a candle if our web media is going to continue to be relevant into the future.

In addition to the variety of operating systems or hardware one might have, there are many different browsers one might use. Oh, and there is a change in the HTML standard with regard to video coming down the pike as well. In anticipation, HTML5 has already been implemented in some form or another in most contemporary browsers.

An extra challenge in making video forward compatible is that the HTML5 <video> tag standard codecs have not been determined. Two top contenders are OGG and H.264. OGG has no patents but it is performance deficient. H.264/MPEG-4 AVC has patents but is easily licensed (for a price) and is backed by Apple. I plan to kill the iPod-iPhone best-bet-on-forward-compatibility birds with the H.264 video, up to 1.5 Mbps, 640 x 480, 30 frames per sec., Low-Complexity version of the Baseline Profile with AAC-LC audio up to 160 kbps, 48 Khz, stereo audio in the ‘mp4′ container (per Apple). Both Handbrake and FormatFactory can do this . Lifehacker reports: “In terms of HTML5 and video, Opera has gone the way of Firefox, supporting native, Flash-free streams of the Ogg Theora format, but not H.264. Apple’s Safari supports only H.264, and Google Chrome supports both.” Mozilla has posted explicit directions for how to make media available for all browsers. Unfortunately, somebody needs to write the java script to generate the player. Sublime video is working on this and has a prototype up at their website. They promise to provide it free for noncommercial use.

The question remains what can one do today? The good news is that if your OS-Browser combo (henceforth to be referred to as your client) can’t play the provided HTML5 video it ignores it. So, I will be providing code for HTML5 video in all cases.

Modifiers for the video tag include controls, preload, and autoplay. The default is not to autoplay so you can leave that out if you just want the video to start loading without playing. Preload=”none” is the default and does not need to be included . Here are a couple of examples from Video for Everybody. The controls inherent to HTML5 (not modified with java script) are basic and don’t allow for moving to full screen. Fortunately, some browsers (thank you Firefox) make this available in the right-click menu. The video will only be as big as will fit in the space provided by the width and height modifiers.

<video width=”320″ height=”240″ controls preload autoplay>
<video width=”320″ height=”240″ controls preload=”none”>

But remember that the source video format depends on the client. The iPhone is even limited as to what the maximum resolution it can play will be. The approach that seems to be evolving on the web is to use the multiple source option for HTML5 video. The browser simply plays the first source that is compatible and ignores the others. Modifiers for the source include specifying the video and audio codecs and/or the container type. An example of using just the container type is given by Video for Everybody (VfE). Here the first is for Firefox, Chrome, and Opera and the second allows the iPhone, iPad, Mac crowd to play and the last lets the non-’mov’ browser play video in the ‘mp4′ container. I did not test this.

<source src=”video.ogv” type=”video/ogg”></source>
<source src=”video.mov” type=”video/mp4″></source>
<source src=”video-desktop.mp4″ type=”video/mp4″></source>

Video on the Web posts most of the parameters related to <source>. Here is their example of two video files with the optional container type and codecs specified. This speeds how quickly the client can reject an unplayable format which speeds load time:

<video width=”320″ height=”240″ controls>
<source src=”NewOrleans2006.ogv” type=’video/ogg; codecs=”theora, vorbis”‘>
<source src=”NewOrleans2006.mp4″ type=’video/mp4; codecs=”avc1.42E01E, mp4a.40.2″‘></video>

But wouldn’t it be nice to offer Flash with its ability to go full screen with just a user click to those clients capable of doing so? (Please don’t rant about the security issues with Flash unless you are one of the few pure ones who live outside of the influence of YouTube, okay?) There appears to have been a lot of attention given to providing Flash as a last resort. This process is described as “degrading” to Flash. The filter works something like this. If the client has a browser (Firefox, Chrome, and Opera) that can handle OGG, it plays the first source and skips everything else within the video tags. If it is a Mac, iPhone, or iPad, it skips the first source and lands on a second source in a ‘mov’ container. If the client is an iPhone or iPod it could play an alternate second source generated using QuickTime Pro. I’m lazy so I’m just going to have on H.264 source small enough that both Mac and iPhone (and presumably iPad) users can share. If one is watching on the web 640 px is plenty wide enough. If I didn’t have doubts about licensing issues I might reverse the OGG versus H.264 order. Finally, an object can be included within the video tags to provide ELSE actions if the client can’t play HTML5 video. In this scenario, the object is flash video. After studying the above sources, I adapted their code for my blog to illustrate their degradation algorithm using my own web host’s flash player. It starts OGG, then filters down to an iPhone file in a ‘mov’ container, then degrades to flash. Since I’m not doing the QuickTime Pro deal, I use the ‘mp4′ container instead of ‘mov’. Currently, this code has been demonstrated to degrade to flash on Internet Explorer 7. When using Opera 10.5, Chrome or Firefox, it plays the ogg file as HTML5 video. It switches to the ‘mov’ HTML5 only on the iPhone. My display is broken on my iBook so I didn’t test with that. My wife’s Eris also handles this well. The relevance of the lead in video is that it is written just like this. (It appears that Firefox 3.5 does not display the poster image, but Firefox 3.6 does. Otherwise the player seems the same.)

<video controls width=”560″ height=”402″ poster=”__Your_Full_Poster_Path__.jpg preload>
<source src=”__Your_Full_Video_Path__.ogv” type=”video/ogg”></source>
<source src=”__Your_Full_Video_Path__.mov” type=”video/mp4″></source>
<object width=”560″ height=”402″ type=”application/x-shockwave-flash”
data=”__Your_Flash_Players_Full_Path__.swf?image=__Your_Full_Poster_Path__.jpg&amp;file=__Your_Full_Video_Path__.flv”> <param name=”movie” value=”__Your_Flash_Players_Full_Path__.swf?image=__Your_Full_Poster_Path__.jpg&amp;file=__Your_Full_Video_Path__” />
<!– fallback image –>
<img src=”__Your_Full_Poster_Path__.jpg” width=”560″ height=”402″ alt=”__Your_Video_Title__” title=”No video playback capabilities” />
</object>
</video>

One little caveat for you WordPress posters. If you switch in the online editor from HTML to Visual view the editor will happily foul up all this wonderful code. Stay in HTML view till you publish and you’ll be just fine. We’ve only scratched the surface of this topic so here are some links to the places I went to to get to this point. Hope you find this all helpful.

Useful Resources:
Video on the Web
Video for Everybody
Sublime Video
Mozilla on HTML5
Lifehacker on Opera 10.5
arstechnica