Almost every non-linear editing system has its own quirks, and often handles video file formats very differently, sometimes with surprising and disastrous side effects.
While helpful in terms of speeding up editing workflows by limiting rendering times, a non-standard file capture from a tape-based format such as DV or HDV creates an adverse effect on encoding for streaming; not just after editing, where concatenation often occurs, but even when raw clips captured by an editing system are transcoded to streaming video formats.
As I mentioned in a previous blog post, I’m writing a white paper on Flash Video choices. In the next week, a few announcements will be made that will have a profound impact on what I’m writing (causing me to both rewrite portions of what I’ve already written as well as re-think the workflow).
Without divulging anything about the announcements (for those, see an upcoming article I’ll write in my contributing editor role at Streaming Media magazine - www.streamingmedia.com - as well as a companion podcast), I’m going to spend some time in this blog post talking about how to pull raw content off both HDV and DV tapes in their respective native formats. I was able to capture and transcode native DV and HDV files, and use the raw files captured on both Mac and Windows platforms on the other platform with a minimum of fuss and extra software. It wasn’t easy, but I’m passing on this helpful information since many of the postings I read on the topic tell only a very small part of the overall encoding and transcoding story.
Why use native formats? Primarily to keep the original footage as close to, well, original as possible. Both HDV and DV are digital formats, so a raw transfer in the video’s native format is no more than a bit-for-bit copy of the video from tape to hard drive. No additional codecs to muck up the original video, no waiting around for video clip rendering, no loss of key metadata that comes with every frame of original video (a pet peeve I’ve worked on since the late 1990s with various levels of success that started with identifying all the lost metadata).
Given the length of the information provided below (I provided what didn't work as well as what worked), I'll cover DV workflows in a subsequent post. For now we'll focus on HDV, which uses MPEG-2 Long Group of Pictures (LongGOP) wrappered in a .M2T exenstion (MPEG-2 Transport Stream, which multiplexes - or muxes - audio and video streams together).
While HDV cameras tout 1920x1080i the video files are, in reality, 1440x1080i with additional lines extrapolated to create a 1920x1080i signal (the lines are added during playback or exporting from an NLE timeline if 1080i files are being exported). Anything captured by an NLE that has other than an .M2T extension will probably have one of two variations on it: extra lines added to the captured video file (to allow for easier 1920x1080 edit workflows) or some form of lossy compression added on top of it.
Methodology
To test HDV and DV capture, I used a tape I’d shot for the white paper I’m writing, on which I had recorded both HDV and DV, with HDV interspersed in five minute segments between DV. In auto-capture mode on most NLE systems, this would result in the auto-capture utility generating an error when it hits the first portion of the tape that had the other format. The NLE tools I used for capture, though, on both the Mac and Windows platform, handily ignored DV when placed in an HDV capture mode and vice-versa).
Speaking of tools, here’s a list of the overall tools I used for native HDV capture, file manipulation and transcoding:
•Canopus Edius Neo (Windows)
•Adobe CS3 Premiere (Mac)
•Apple’s iMovie 08 (Mac - didn’t work)
•Apple’s Final Cut Pro 6 (Mac - didn’t work)
•Handbrake (Mac, Windows)
•MPEG StreamClip (Mac, Windows)
•Sorenson Squeeze 4.57 (Mac, Windows)
•On2’s FlixPro 8.53 rc3 (Mac, Windows)
•QuickTime Alternative 1.81 (important) (Windows)
•QuickTime MPEG-2 Playback Component (Mac)
After capture, I immediately attempted a transcode from the native format to a one of several video streaming formats, including Flash (On2’s VP6 or Sorenson’s Spark) or H.264, gauging whether the applications were able to understand native HDV and DV format extensions (.M2T and .DV) or instead required some form of massaging (but not extra transcoding) to reach a point where a streaming file could be created.
No transcodes were attempted from the NLE’s timeline. This limitation was one part pragmatic (an attempt to avoid extra renders and concatenation issues) and one part self-challenge (to see whether the statement, which I’d seen on several forums, that HDV or DV files couldn’t be used cross platform without rendering was true).
Given the length of these topics, and variations in workflow, I’m going to cover HDV in this post and DV in a subsequent post.
HDV Capture and file preparation - Windows Workflow
If you’re starting out on the Windows platform, a good encoding product that captures raw HDV in its native M2T format is Canopus Edius. This NLE comes in two flavors (Pro and Neo); I chose Neo because its focus is strictly native HDV and DV.
Edius Neo did a good job of ignoring the clips that were DV and capturing only the HDV footage, which it then broke down into clips based on each time I’d hit the record button to start or stop the recording (Canopus calls this “clip divisions”). In the bin and on the editing timeline, Neo presents timecode start/stop times but the same clips in Windows Explorer are only numbered sequentially - Cap000(001).m2t, Cap000(002).m2t, etc. This failure to correlate file names in any way back to the original tape footage makes manual naming critical for these files before moving to the next step.
Now that you have a .M2T file, have closed Edius and renamed the file to an appropriate name that corresponds to timecode or date of the captured tape, you’re done if you only plan to do H.264 or MPEG manipulations from a program like MPEG Streamclip or Handbrake. To find out about these, see theHDV Transcoding section below.
HDV Capture - Macintosh Workflow
Capture of HDV files on a Mac is both more intuitive and more difficult than HDV capture on a Windows machine. More intuitive because the captured footage is named for the time (hour;minute;second) of the initial frame of each clip of footage; and it’s not the time it was transferred to the computer but, rather, the time stamp on the videotape for the starting frame of the day it was captured. This naming convention, coupled with timecode information in the bin, would make the capture of HDV footage on a Mac ideal.
Yet that’s where the frustration comes in to play; the only programs on the Mac that support native HDV editing are the new Adobe CS3 Premiere Pro (a sister product to CS3 Premiere Pro for Windows) and Final Cut Pro 6. Premiere can be purchased as a point product, but Final Cut Pro 6 can only be purchased as part of the Final Cut Studio 2 suite. So you can’t get into native HDV capture, let along editing, on the Mac for less than $600 (or less than $1200 if you buy Final Cut Studio 2 or Adobe’s CS3 Production Premium, the suite that contains Premiere Pro for the Mac). Apple’s lower-end products, such as the simple but great iMovie 08 (version 7) and Final Cut Express 4, both released AFTER Final Cut Pro 6 and running on Macs more powerful than those that Apple says are the minimum for native HDV editing, still are crippled by the Apple Intermediate Codec (AIC) which isn’t supported by QuickTime on the Windows platform. Ugh.
It really is too bad, because iMovie 08 (bundled with new Macs as part of iLife 08) does a great job with DV in a native format, plus it excels in ignoring footage in other formats during capture, plus logging, naming, splitting clips and automatically creating a folder structure that integrates nicely with the OS. Even the new Final Cut Express 4, an ideal base-level system feeding up to Final Cut Pro uses that stupid AIC codec, so no true HDV feeder system exists on the Mac.
Feel the frustration? It has to do with the fact that AIC is a lossy codec; if it were lossless, like Apple’s ProRes422, native HDV capture would be viable.
So, anyway, we captured footage in Apple’s Final Cut Pro 6 which lists native HDV capture as one of its selling points. But, and this is a major but: while you can get HDV content into FCP, getting it out (even the scratch files) is next to impossible. We’ll talk about that below, in its own separate section, as it takes alot of explaining and shows FCP is behind the times on HDV.
So we switched to CS3 Premiere Pro. It worked like a charm and output a lovely .MPG file, which we renamed to .M2T and proceeded with life, just as easily as the Canopus Edius Neo scenario on Windows XP. Premiere lacks the grace of intelligent logging in Edius and Final Cut (all trumped by iMovie 08’s excellent logging). As a Mac program capturing raw HDV transport streams, though, Premiere trounces iMovie, FC Express and FCP.
Once you are done capturing in CS3 Premiere Pro, quit the program and rename the files to match some reference to your original capture and then proceed to transcoding change the extension from .MPG to .M2T. This will give you access to Handbrake and MPEG Streamclip, which you’ll need, respectively, to convert to .MP4 (H.264) and demux the MPEG-2 transport stream to elementary streams, or separate audio and video files. The latter step is required if you want to use native HDV footage in On2’s Flix Pro which doesn’t have native MPEG-2 demux capability.
HDV Transcoding - Windows and Mac Dual Workflow
So what programs work cross-platform for manipulation of raw HDV files? We’ve mentioned three so far: Sorenson Squeeze, MPEG Streamclip and Handbrake. And we’ll add a fourth, which requires a bit of manipulation: On2’s Flix Pro 8.53 rc3 (tested in release candidate 3).
Each of the first two tools can manipulate files with the .M2T extension. Both handle .M2T completely fine, with Handbrake requiring the .M2T extension to work properly (a .MPG yields an invalid file type). MPEG Streamclip using QuickTime Alternative (QTA) on Windows to transcode to many file types or to further demux for use on other programs that can’t handle the .M2T extension; on the Mac, is uses the MPEG-2 Playback Component.
If you’ve not heard of Handbrake, you’re in for a surprise. This open-source, multi-threaded cross-platform program offers an excellent way to generate good 1280x720 H.264 files directly from .M2T files, demuxing both audio and video automatically as it creates and re-muxes H.264 versions of files. Given its heritage - a program designed to rip DVDs into H.264 movie files - it is also very fast, almost 15 times faster than Sorenson Squeeze’s H.264 encodes. It ouptuts a better transcode, too, which is surprising as Sorenson Squeeze uses 5 or more passes to Handbrake’s 2-pass transcoding.
Handbrake is available on Mac and Windows, so .M2T files can be opened and transcoded from directly with no other manipulation. Handbrake’s primary downside, though, appears during multi-file encodings, as it both lacks a watch folder and has the most antiqued batch queueing system I’ve seen in quite some time: every file must be added manually to the queue, even if every file is going to have the exact same manipulation. Given the laborious batch queuing process, plus instability which yielded repeated failures after the 6th transcode in a long batch queue list (failures occurred on several test Mac systems), the encoding speed is mitigated by the need to constantly monitor the software. Once that issue is addressed, though, this is a very good H.264 contender.
MPEG Streamclip is another free program, which requires a free additional tool (QuickTime Alternative) on Windows and a paid additional tool (QuickTime’s MPEG-2 Playback Component) on a Mac; we’ve also found MPEG Streamclip can be used to decode .M2T files on any Mac with Compressor loaded on it. This is a must-have tool.
MPEG Streamclip works quite nicely if you follow the directions closely, especially on Windows machines. The underlying tool required on Windows is called QuickTime Alternative (QTA). MPEG Streamclip requires version 1.81 for its MPEG-2 codecs (newer QTA versions, including the new v2, lack the MPEG-2 codecs found in version 1.81). Adding a newer version of QTA to MPEG Streamclip creates a vicious circle that appears to render the program unusable for our main goal: demuxing .M2T files into separate video and audio files (elementary streams) for use of HDV files in programs such as On2 Flix Pro.
Sorenson Squeeze, one of the premier transcoding tools, with an excellent batch encode setup and a great watch folder capability (it checks a folder for any new files to transcode into one or multiple new streaming files) can access and transcode from a native HDV file file with one simple change: change the file’s .M2T extension to an .MPG extension and Sorenson will demux and use the file to create transcodes in a wide variety of formats. Squeeze has a native MPEG-2 demuxer built right in which means it’s a tool that can be used for almost everything, with the exception of VP6-S - On2’s new simple profile HD-capable version of VP6. If time isn’t a factor, because the product is painfully slow (but not quite as slow as Compressor).
HDV Playback - Windows and Mac
Changing a .M2T file to a .MPG extension allows Windows Media Player (WMP) to play the files with no additional manipulation, even on the expired demo version of the Elecard MPEG-2 WMP decoder. Likewise, QuickTime Alternative 1.81 can use a Classic Media Player to play content on Windows boxes. The player, though, don’t work cross-platform even with .MPG-named files: Windows Media Player, as its name implies, is only available on Windows.
QuickTime on the Mac (even with the $20 MPEG-2 Playback Component) yields a white screen for .MPG files that have been changed from .M2T files. The Mac QuickTime player also balks at .M2T files saying, simply, “This file is not a movie file.” - doubly ironic since the MPEG-2 Playback Component for QuickTime is required for MPEG Streamclip on the Mac to read and demux .M2T files into .M2V video and AIFF audio files which then play fine via QT’s MPEG-2 Playback Component, linking both audio and video files together to play simultaneously, as long as they are named the same (minus extensions, of course) and in the same folder.
Your choice for cross-platform playback? MPEG Streamclip, with the tools mentioned above for each respective platform. At least you didn’t waste $20 on the MPEG-2 Playback Component for QuickTime for Windows ;)
[Note: while the files showed timecode information in the Canopus Neo bin and on Neo editing timeline, the information is lost during the demuxing to .M2V and AIFF via MPEG Streamclip; the same is possibly true with CS3 Premiere files but no testing was done to confirm this scenario.]
Posts
No comments:
Post a Comment