Convert AVCHD (.MTS) video to mp4, avi, or mov

A number of digital cameras these days are capable of shooting 1080 HD video, but unfortunately, many cameras use the AVCHD format that was jointly developed by Sony and Panasonic. The use of this proprietary container can make playback on many devices and computers problematic.

Neither the less expensive Windows 7 versions nor Mac OS 10 versions prior to 10.8 (Mountain Lion) support native playback. I've also found the same issue with Android. Of course VLC is always a good desktop solution, and there are a number of Android players, such as MX Player.

Quickly googling for converting between MTS and MP4, etc. brings up a lot of solutions, but few are desirable because they transcode the video and audio streams. This is not only a waste of time and CPU cycles, quality will deteriorate. The thing is, inside these files are streams encoded with standard codecs that should be playable on anything - if not for the annoying AVCHD container. Most likely, the video stream inside a ".mts" file is h.264 video. There is no reason to re-encode the video to h.264 just to get an AVI, MOV, or MP4/M4V file.

So I use ffmpeg to just change the container, while keeping the streams intact and untouched, by using the copy options for the video and audio codecs. If you already have ffmpeg installed, all you have to do to get an mp4 file is type this from your command line (while in the proper directory).

ffmpeg -i input.MTS -vcodec copy -acodec copy output.mp4

To get an AVI or MOV file, just change the name of the output file accordingly (output.avi or output.mov). For whatever reason, Quicktime on Mac OS 10.7 doesn't like these mp4 files and changing the extension to m4v does not fix the problem. For quicktime playback, change the containter to MOV (e.g., output.mov).

This simply copies the existing streams into a new container. Be warned, though, that this might not copy all streams and probably won't include any embedded GPS data. (Here is a neat tool for extracting GPS data from these containers.)

In case you want to batch process files, here is a bash shell script (inspired from here) for either mac OS 10 or Linux (sorry windows users). From "for" to "done" is all one line.

#!/bin/bash
for a in `ls *.MTS` ; do ffmpeg -i $a -vcodec copy -acodec copy `echo "$a" | cut -d'.' -f1`.mp4 ; done
exit

Copy the above text to a text editor (not a word processor) and save as any name you like (e.g., mts2mp4.sh and either add it to you path or save it to the same folder as the video files. Give it execute permissions,

chmod +x mts2mp4.sh

And, if the script is in the same folder as your videos (i.e., not added to your path), then execute by doing the following:

sh ./mts2mp4.sh

Mac users might find it useful to install macports to get quick access to a large number of ported *nix applications. To install with macports, first update the list of ports, then install as follows:

sudo port selfupdate
sudo port install ffmpeg

As mentioned above, this isn't a perfect conversion. Using ffprobe on both the original and new files, I notice several inconsistencies. Here is the relevant information from the original:

Duration: 00:00:49.08, start: 0.718789, bitrate: 16880 kb/s
Program 1
Stream #0.0[0x1011]: Video: h264 (High), yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 59.96 fps, 59.94 tbr, 90k tbn, 59.94 tbc
Stream #0.1[0x1100]: Audio: ac3, 48000 Hz, stereo, s16, 192 kb/s
Stream #0.2[0x1200]: Subtitle: pgssub

And from the mp4 file:

Duration: 00:00:49.11, start: 0.033000, bitrate: 15999 kb/s
Stream #0.0(und): Video: h264 (High), yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 15808 kb/s, 59.94 fps, 59.94 tbr, 30k tbn, 59.94 tbc
Metadata:
creation_time : 1970-01-01 00:00:00
Stream #0.1(und): Audio: ac3, 48000 Hz, 2 channels, s16, 192 kb/s
Metadata:
creation_time : 1970-01-01 00:00:00

Notice that there is a slightly different bit rate to the video, changed duration and start time, only two streams (no subtitle file - gps data(?)), and a bogus creation data on both streams. I am guessing some of these changes to stream properties might be related to container limitations on perhaps I-frames or something (but really have no idea).

Anyways, the conversion works and the videos play!