Thursday, December 13, 2007

What Is Up WIth Final Cut 'Native' HDV Capture?

A recent blog post discussed both Windows and Macintosh workflows to capture and transcode native HDV files.


While options available on both platforms, namely Adobe CS3 Premiere Pro and Canopus Edius Neo (or Pro), there’s one other wildly popular editing tool that claims native HDV that didn’t stand up to the native HDV test.


In the course of testing HDV workflows we put Final Cut Pro 6 through its paces to see if its HDV capture would play nice with programs that expected, well, native HDV support in terms of an .MPG or .M2T extension. Surprising results.

So What’s Up with Final Cut and HDV?

It does capture HDV, but not in the standard .M2T (or even .MPG) extension. Final Cut’s scratch captures are listed as .MOV files and the Movie Inspector in QuickTime shows the footage as HDV1080i60, with the HDV resolution the correct 1400x1080 (1888x1062) and the frame size as 1920x1080, meaning that it is correctly extrapolating the additional lines. So far so good.


But converting Final Cut’s HDV footage (even the scratch footage) in to an .M2T extension isn’t so easy, as Apple apparently is doing something with its HDV files that adds a proprietary twist to the files. Changing the extension to .M2T did absolutely nothing; changing it to .MPG also did nothing, and any extension confused Handbrake enough that the “beach ball hell” kicked in and never stopped.


Another confirmation that the Apple HDV files wasn’t conforming to the HDV MPEG-2 LongGOP spec was the fact that MPEG Streamclip could open it on the machine on which it was captured (ie, a Mac that had Final Cut Pro 6 installed) but opening it on any other Mac with the MPEG-2 Playback Component only yielded a white screen in the MPEG Streamclip window with an audio bar directly across the middle. So the audio would play but nothing else. Oh, and on no Mac would MPEG Streamclip ungrey the option to demux the MPEG-2 file, probably because it wasn’t an MPEG-2 file and therefore not in a native HDV format ;)


Compare this to CS3 Premiere Pro, which output a .MPG file which we changed the name on to a .M2T extension, loaded it up in Handbrake and spit out a .MP4 file, flipped over to MPEG Streamclip and demuxed a .M2V video file and and an AIFF audio file (just as MPEG Streamclip on Windows had done) and then opened the latter the M2V in QuickTime Player, where the audio was automatically linked to it.


Saved that MPEG-2 1440x810 resolution file out as a .MOV (didn’t export, just did a “Save As”) and now had a native HDV and a native MPEG-2 MOV to work from on almost any Flash transcoding system. Oh, and changed the extension of the .M2T back to .MPG and opened it up in Sorenson with no problem at all on a separate Mac machine that didn’t have Premiere or the MPEG-2 Playback Component loaded on it ;)


And don’t get me started on Apple’s Intermediate Codec (AIC) used in iMovie 08 and Final Cut Express 4; this lossy compression isn’t supported by QuickTime for Windows, plus yields additional concatenation issues. Bad move and poor timing as the new Final Cut Express 4, with its price reduced to $199, would be an ideal base-level system feeding up to Final Cut Pro as iMovie 08 feeds into Final Cut Express 4. And Apple can’t say AIC is used because the machines don’t have enough power or storage: FCE and iMovie 08 are both running on Macs more powerful than those that Apple says are the minimum for native HDV editing.


Almost workable on a single platform except for that stupid AIC codec. And no support at all for moving either FCP’s ‘native’ HDV or iMovie and FCE’s AIC files to Windows. I love my Mac and use it for almost every video test I do, but now have to settle for Adobe CS3 Premiere Pro to get true native HDV out of the Mac. Triple ugh.

Monday, December 10, 2007

Working with Native Digital Video Formats - DV

A companion post to the previous post on HDV native formats and workflows, this one explores DV workflows, which are often much simpler than those of its high-definition cousin.


DV, short for MiniDV, used to be considered a professional format and still is, in many ways. It’s a format, though, that’s used by many more consumers than professionals, thanks to price drops in recent years as HDV and other high-definition and disk-based formats have entered the market.


This post assumes knowledge of the HDV post.


In a blog post last week, I walked through the workflow of capturing raw HDV files and preparing them for transcoding to Flash video formats. Today's post focus on the same workflow for DV.


Before I start, though, an update on the mystery announcement I mentioned: Adobe announced, on December 4, the final configuration and pricing for Flash Media Server 3 (FMS3). With an eye toward streaming and interactive (two-way or multi-way) video, FMS3 is now available in two flavors: the lower-priced, single-box Flash Media Streaming Server and the higher-priced, scaleable Flash Media Interactive Server. Both FMSS and FMIS will be available in January 2008. For more details seehttp://www.streamingmedia.com/article.asp?id=9774 for an article and a companion podcast.


So back to DV; you might remember I’m writing a white paper on Flash Video choices, which includes shooting some clips to compare HDV and DV workflows as well as the perceived qualities of the resultant transcodes to various Flash video codecs. To test workflows, the raw files were captured in their native formats on both Mac and Windows platforms, and then moved the files cross-platform without requiring transcoding to any other video codec.


We talked about this last time, but it bears repeating: why use native formats? Besides the ability to do a bit-for-bit copy, there's also no need to spend additional time transcoding when moving cross-platform, and no surprises when an intermediate codec (like Apple's AIC, which is used for HDV in its iMovie and Final Cut Express products) isn't supported on the other platform. Plus native formats contain a significant amount of helpful metadata that's stripped away when an intermediate codec is used.


DV uses a Motion-JPEG codec, wrappered in a .DV extension, or .AVI or .MOV if you are capturing in QuickTime or on a Windows Type II DV format, respectively).


Methodology

To test DV capture, I used a tape I’d shot for the white paper I’m writing, on which I had recorded both DV and HDV. Every five minutes, a DV recording was interspersed with an HDV recording. 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, were chosen because they handily ignored HDV when placed in an DV capture mode. In the DV capture sequence, HDV was rendered as a blank screen, which looks similar to the capture locking up, except the screen's timecode display continues to advance.


Speaking of tools, here’s a list of the overall tools I used for native DV capture, file manipulation and transcoding:

  1. Canopus Edius Neo (Windows)

  2. Canopus DV File Converter (Windows)

  3. iMovie (from iLife 08) (Mac)

  4. MPEG StreamClip (Mac, Windows)

  5. Sorenson Squeeze 4.57 (Mac, Windows)

  6. On2’s FlixPro 8.53 rc3 (Mac, Windows)


After capture, the next step was to immediately attempt a transcode from the captured 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 DV format extension (.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 in an attempt to avoid extra renders and the concatenation issues that often plague NLE exports to intermediate files.


Opening the raw file in the transcoding tool worked some times, but other times it didn't work either because of the native file format's original wrapper or the transcoding tool's inability to see particular multiplexing (interleaving) files. Then I needed to do a bit more work so, if a file's extension needed to be changed or a wrapper modified, this was accomplished at the operating system level or through the use of stand-alone software.


DV Capture and file preparation - Windows Workflow

In my previous post, I mentioned that I chose Canopus Edius Neo (the lower-priced cousin of Edius Pro) because its focus is strictly native HDV and DV. The program was adroit at capturing DV clips and ignoring HDV segments of the tape, just as it had ignored DV while capturing HDV. Captures were then broken down into "clip divisions" which corresponded to each time I’d hit the record button to start or stop the recording.


As with the clip divisions for HDV, Neo presents timecode start/stop times in the bin and on the editing timeline, but doesn't carry this over to the naming of clips at the OS level: 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.


The next step, after capturing the clips and renaming them is to close Edius Neo and open another program called Canopus DV File Converter. Canopus' proprietary DV wrapper and extension don't change the DV bit-for-bit content, but the way it interleaves audio and video content does make it nearly impossible to open the files in another program to transcode files to Flash streaming formats.


DV File Converter has one function: convert between Canopus DV format wrapper and other types of DV wrappers, including DV Type I and DV Type II AVI files. All of these formats store the exact same bit for bit copy of the DV video clip, but some of them write the files to disk differently (interleaving audio in different ways, for instance). Focus Enhancements, the company that I think best grasps the vagaries of different DV formats, has a good cross-reference on DV file formats. Some of these files show up at 720x480 while others show up as 640x480 resolution.


The program introduces no quality loss and can save in both Microsoft's DV Type I and Type II wrapper (both in an .AVI extension). As is typical of naming conventions, MSDV Type I is newer (and was used for Movie Maker 2) while MSDV Type II is older and was used in Movie Maker 1. Confused yet? Don't be; just use Type I as that can also be opened in anything that understands QuickTime, whether on the Mac or Windows platforms.


DV File Converter works extremely quickly, rewrappering the Canopus DV files and putting them into the .AVI extension, with no quality loss. The .AVI files can then be used by many transcoding programs on the Windows platform, including Sorenson Squeeze, which uses QuickTime as a portion of its underlying engine.


The files can also be transferred to a Mac and used as is, but a quick note of caution: since the MSDV codec also has its own unique interleaving scheme, don't attempt to change the file extension from .AVI to .DV for either MSDV Type I or Type II. I did tests on both types and was rewarded with digital snow throughout the image, probably due to the need to way audio is interleaved. Fortunately the damage wasn't permanent as I was able to change the extension back to .AVI and the file worked flawlessly again.


DV Capture and File Preparation - Macintosh Workflow

All I can say is that I'm impressed with iMovie 08 (bundled free with new Macs as part of iLife 08). Not only does it do a great job with DV in a native format, it excels in ignoring footage in other formats during capture, just like Canopus' Edius Neo did.


In addition, and to me this is where iMovie 08 really shines, the automatic capture segments everything in the bin (and at the operating system level) by clip name that includes the time (hour;minute;second) of the initial frame of each clip of footage. It’s not the time it was transferred to the computer, which has no bearing on either timecode or the day a segment was recorded; instead, the time stamp is metadata from the video tape itself, and indicates the starting frame of the day and time it was recorded.


This naming convention, coupled with timecode information in the bin, automatic splitting of clips (like Edius Neo) and automatic folder structure creation both in the bin and at the OS level, makes iMovie 08 idealf for that integrates nicely with the OS. And no stupid intermedia codec, such as the AIC I was ranting about in the previous post; these files, output in a .MOV extension, can be used cross platform with no difficulty at all, including no name changes if the transcoding tool is capable of handling QuickTime files.


DV File Preparation - both Mac and Windows

I thought this deserved a separate mention, since it works on both Mac and Windows boxes: MPEG Streamclip, which was discussed in the previous post as a good way to demux (separate) MPEG-2 transport streams into individual elementary streams (separate audio and video files) also has a useful DV feature. One of the options is Export to DV which has its own extra trick: a very good de-interlacer. I've tried it on numerous files and it not only does a good job of deinterlacing DV footage, making it appear sharper as a standalone .DV file, but it also carries that sharpness through into transcodes for Flash video codecs.


On top of that, the file size is reduced in half, thanks to the way MPEG Streamclip handles deinterlacing, but QuickTime views the data rate of the file as if it were the original size. I at first thought my eyes were playing tricks on me, and I would caution additional testing if you're going to use these DV files cross platform or the video is critical, but it's an amazing bit of workI hope the guys at Squared5 (www.squared5.com) can shed light on.


DV Transcoding - Macintosh and Windows

Once you are done capturing and have made any file preparation changes to DV wrappers or file extensions, it's time to transcode the files. MPEG Streamclip can output to On2 VP6 and H.264, but for final clarity, I recommend using On2's FlixPro 2.5 or greater for Flash 8 Video (VP6-E) output and Sorenson Squeeze for all other outputs to Flash (Spark, H.264).


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 an DV file in the .AVI or .MOV or .DV file extension. On2’s Flix Pro can do the same thing and provides On2’s stellar VP6 support (including, soon, VP6-S simple profile for HD 720p files).

Monday, December 3, 2007

Working with Native Digital Video Formats - HDV

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:

  1. Canopus Edius Neo (Windows)

  2. Adobe CS3 Premiere (Mac)

  3. Apple’s iMovie 08 (Mac - didn’t work)

  4. Apple’s Final Cut Pro 6 (Mac - didn’t work)

  5. Handbrake (Mac, Windows)

  6. MPEG StreamClip (Mac, Windows)

  7. Sorenson Squeeze 4.57 (Mac, Windows)

  8. On2’s FlixPro 8.53 rc3 (Mac, Windows)

  9. QuickTime Alternative 1.81 (important) (Windows)

  10. 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.]