<p>I agree with what @MoritzLost said.  Better that you copy those video files directly.</p>

<p>Once you have these MTS files copied, there are a variety of options.  I ran into this problem myself recently and found the two best options were rather simple (despite lots of complicated discussions online):</p>

<ol>
<li><p>Simply rename (or copy first and rename the copy) the video file from a .MTS extension to .MP4 extension.  </p>

<p>Sounds a bit stupid, but the video and audio are generally supported by lots of different programs.  Problem is, the MTS container surrounding the video and audio streams us bit as well supported.  Give this a try first, because it's the easiest thing to do with keeping the audio and video quality exactly as it is in the original file.</p></li>
<li><p>The next best option I found was using ffmbc.  You can find the website for it (which will eventually be unsupported or removed completely) at: <a href="https://code.google.com/p/ffmbc/" rel="nofollow">https://code.google.com/p/ffmbc/</a> .  There is also a Google Groups website for it at: <a href="https://groups.google.com/forum/#!forum/ffmbc-discuss" rel="nofollow">https://groups.google.com/forum/#!forum/ffmbc-discuss</a> .  For the Windows version, you'll find a download on the Groups website, while for Mac and Unix/Linux, you can download and build the code yourself (sorry, I can't help you with building on a Mac).</p>

<p>After you have the program built, you can run the following command:<br />
<code>ffmbc -fflags +genpts -i "FILENAME.MTS" -vcodec copy -acodec copy "FILENAME.mp4"</code></p>

<p>Obviously, you'll need to make sure ffmbc is runable from the command line of whichever OS you are using...otherwise, you can use the full path to the ffmbc executable.  And change "FILENAME" to be the name of whatever file you are using.</p>

<p>**From my experience, you will find the resulting file to be smaller.  For some reason, the MP4 container format is more efficient than the MTS container format.  You could research the reasons behind this, if you're interested.  Anyway, I have found that with a 6.1 GB file, repackaging an MTS file drops to about 5.7 GB.  The time it took to repackage that particular file from MTS to MP4 was about 1m 30sec.  So, even if you have incredibly large files, you are not looking as nearly the length of time that you would for re-encoding the video/audio.</p></li>
<li><p>You could also try using ffmpeg, MP4Box, Libav, are a variety of other tools.  The key here is that you do not need to re-encode the audio or video (unless you want/choose to).  You simply want to change the container that "holds" the video and audio streams.</p></li>
</ol>

<p>**Generally speaking, the AAC audio format is better supported and standard for MP4.  So, you might want to copy the video stream but re-encode the audio if the application or media player you're using doesn't support AC3 (the default MTS audio format).  Re-encoding the audio won't take much extra time, but will add time compared to simply repackaging the video/audio in a different container.</p>

<p>Also, if you need to change anything, such as framerate, resolution, audio bitrate, etc., then you'll need to re-encode the audio or video (or both).  But, if you literally want the audio/video to be the same, the container change is your best choice <em>and</em> the fastest (with the exception of if renaming the extension MP4, if this works for your purposes).</p>

CC BY-SA 3.0
2015-12-17T07:30:27.603Z
ffmpeg will be more current than ffmbc, and if you're not encoding to an exotic production codecs or containers, is generally unnecessary.
Gyan
CC BY-SA 3.0
2015-12-18T10:05:00.613Z
What you are saying is only partially true.  Yes, ffmpeg is more current.  Regarding "exotic production codecs"...well, ffmbc also supports most/all of the same "non-exotic" codecs that ffmpeg does.  Problem is the issue that was posted here on Stack Exchange a year ago, listed here: [link](https://video.stackexchange.com/questions/12156/how-can-i-convert-mts-file-avchd-to-mp4-by-ffmpeg-without-re-encoding-h264-v).  Basically ffmpeg changes from 29.97 fps to 59.94 fps.  Unless you know a way around this, using ffmbc to maintain the **correct** fps of the original MTS video is better.
whatisit
CC BY-SA 3.0
2015-12-18T10:14:11.223Z
As an additional point, if the @lewlsaucengravy uses ffmpeg and doesn't have a problem with with the fps changing, then ffmpeg is perfectly fine to use.  I am hesitant to suggest it given my problem and others' with the fps changing when changing the container from MTS to MP4.
whatisit
CC BY-SA 3.0
2015-12-18T11:20:32.820Z
That old question presents a complicated case. See the answer I just posted there. Note that the output I produced for a similar file - interlaced HDMV/AC-3 in MTS to MP4 with copying video stream - plays properly. And progressive H264 will mux fine. And all H264 streams will transcode correctly with ffmpeg. So, unless the OP needs to mux the current stream, my suggesrion stands.
Gyan
CC BY-SA 3.0
2015-12-19T12:11:54.710Z
I had the same issue as that post...I don't see it as being overly complicated.  That person attempted multiple things which made his post long and complicated, however.  As as you wrote in that thread, it played properly for you.  That poster said in his post that it did not play properly for him.  If it works for you, great.  However, I posted this answer based on my problem experience with fps and that other people who have posted here obviously had the same problem.  Also remuxing = copying video/audio stream into a different container.  So...I don't really follow your last sentence.
whatisit
CC BY-SA 3.0
2015-12-19T12:58:04.220Z
The OP here hasn't indicated that they need to stream copy. They just want a smoothly playing file that doesn't look "pretty crappy". Your 2nd option suggests ffmbc in order to remux the video stream. I suggested ffmpeg since it will be current (in terms of bugfixes and features).
Gyan
CC BY-SA 3.0
2015-12-19T12:58:30.653Z
What I meant by "complicated" in the case you cite is the problem there is not a generic bug of ffmpeg failing to preserve framerate during a MTS to MP4 remux but that when ffmpeg muxes a non-spec H264 interlaced stream with merged field pairs into an in-spec stream, thus separating each field, the frame rate analysis goes haywire. For this OP, that's not an issue since the 60fps mode in their camera only shoots progressive for which ffmpeg poses no problem.
Gyan
CC BY-SA 3.0
2015-12-19T12:58:34.523Z
I guess my chief objection was that your solution made it sound like ffmpeg can't handle MTS well, whereas it's that if you give it an *out-of-spec* H264 il stream to mux, the resulting file will show a wrong framerate. That's a niche case, not applicable to this OP and the preference for ffmbc not advisable in general.
Gyan
CC BY-SA 3.0
2015-12-17T07:13:49.883Z
2016-01-06T20:09:53.953Z
2016-01-06T20:09:53.953Z
whatisit
<p>Still learning a little bit about converting formats, fps, etc. </p>

<p>I have a Sony A6000 and have the option to record in 1080 at 60fps. This is perfect for me because I absolutely love the smoothness of it. However, when I import it into my Macbook using PlayMemories Mobile, it imports the .MTS file (perfectly fine) and converts it into MP4. The problem is that the MP4 file looks pretty crappy compared to the original one. Very choppy, etc.</p>

<p>Is there any better way that I can handle this? How do other people record 1080 at 60fps and upload videos to YouTube? I'd like to be able to accomplish the same goal, but have no idea how to. I hope this all makes sense, although I'm sure I'm misunderstanding something here.</p>

<p>I'd love to maintain 60fps if possible during the conversion.</p>

CC BY-SA 3.0
2015-04-10T10:18:21.590Z
So this program that you use (Playmemories Mobile) converts your videos upon importing? Why do you use it then? Have you tried copying your video files directly from the camera to your macbook?
MoritzLost
<video-quality>
Convert MTS 1080/60p to MP4 1080/60p
lewlsaucengravy
# Convert MTS 1080/60p to MP4 1080/60p

(Asked by: username_0 on 2015-04-07)

Still learning a little bit about converting formats, fps, etc.

I have a Sony A6000 and have the option to record in 1080 at 60fps. This is perfect for me because I absolutely love the smoothness of it. However, when I import it into my Macbook using PlayMemories Mobile, it imports the .MTS file (perfectly fine) and converts it into MP4. The problem is that the MP4 file looks pretty crappy compared to the original one. Very choppy, etc.

Is there any better way that I can handle this? How do other people record 1080 at 60fps and upload videos to YouTube? I'd like to be able to accomplish the same goal, but have no idea how to. I hope this all makes sense, although I'm sure I'm misunderstanding something here.

I'd love to maintain 60fps if possible during the conversion.

**Tags:** video-quality

> **Comments:**
> **username_1**: So this program that you use (Playmemories Mobile) converts your videos upon importing? Why do you use it then? Have you tried copying your video files directly from the camera to your macbook?  

---

## 1 answers

### Answer by username_2 on 2015-12-17. Score: 1

I agree with what @username_1 said. Better that you copy those video files directly.

Once you have these MTS files copied, there are a variety of options. I ran into this problem myself recently and found the two best options were rather simple (despite lots of complicated discussions online):

1. Simply rename (or copy first and rename the copy) the video file from a .MTS extension to .MP4 extension.

   Sounds a bit stupid, but the video and audio are generally supported by lots of different programs. Problem is, the MTS container surrounding the video and audio streams us bit as well supported. Give this a try first, because it's the easiest thing to do with keeping the audio and video quality exactly as it is in the original file.
2. The next best option I found was using ffmbc. You can find the website for it (which will eventually be unsupported or removed completely) at: <https://code.google.com/p/ffmbc/> . There is also a Google Groups website for it at: <https://groups.google.com/forum/#!forum/ffmbc-discuss> . For the Windows version, you'll find a download on the Groups website, while for Mac and Unix/Linux, you can download and build the code yourself (sorry, I can't help you with building on a Mac).

   After you have the program built, you can run the following command:  
   `ffmbc -fflags +genpts -i "FILENAME.MTS" -vcodec copy -acodec copy "FILENAME.mp4"`

   Obviously, you'll need to make sure ffmbc is runable from the command line of whichever OS you are using...otherwise, you can use the full path to the ffmbc executable. And change "FILENAME" to be the name of whatever file you are using.

   \*\*From my experience, you will find the resulting file to be smaller. For some reason, the MP4 container format is more efficient than the MTS container format. You could research the reasons behind this, if you're interested. Anyway, I have found that with a 6.1 GB file, repackaging an MTS file drops to about 5.7 GB. The time it took to repackage that particular file from MTS to MP4 was about 1m 30sec. So, even if you have incredibly large files, you are not looking as nearly the length of time that you would for re-encoding the video/audio.
3. You could also try using ffmpeg, MP4Box, Libav, are a variety of other tools. The key here is that you do not need to re-encode the audio or video (unless you want/choose to). You simply want to change the container that "holds" the video and audio streams.

\*\*Generally speaking, the AAC audio format is better supported and standard for MP4. So, you might want to copy the video stream but re-encode the audio if the application or media player you're using doesn't support AC3 (the default MTS audio format). Re-encoding the audio won't take much extra time, but will add time compared to simply repackaging the video/audio in a different container.

Also, if you need to change anything, such as framerate, resolution, audio bitrate, etc., then you'll need to re-encode the audio or video (or both). But, if you literally want the audio/video to be the same, the container change is your best choice *and* the fastest (with the exception of if renaming the extension MP4, if this works for your purposes).

> **Comments:**
> **username_3**: ffmpeg will be more current than ffmbc, and if you're not encoding to an exotic production codecs or containers, is generally unnecessary.  
> **username_2**: What you are saying is only partially true.  Yes, ffmpeg is more current.  Regarding "exotic production codecs"...well, ffmbc also supports most/all of the same "non-exotic" codecs that ffmpeg does.  Problem is the issue that was posted here on Stack Exchange a year ago, listed here: [link](https://video.stackexchange.com/questions/12156/how-can-i-convert-mts-file-avchd-to-mp4-by-ffmpeg-without-re-encoding-h264-v).  Basically ffmpeg changes from 29.97 fps to 59.94 fps.  Unless you know a way around this, using ffmbc to maintain the **correct** fps of the original MTS video is better.  
> **username_2**: As an additional point, if the @username_0 uses ffmpeg and doesn't have a problem with with the fps changing, then ffmpeg is perfectly fine to use.  I am hesitant to suggest it given my problem and others' with the fps changing when changing the container from MTS to MP4.  
> **username_3**: That old question presents a complicated case. See the answer I just posted there. Note that the output I produced for a similar file - interlaced HDMV/AC-3 in MTS to MP4 with copying video stream - plays properly. And progressive H264 will mux fine. And all H264 streams will transcode correctly with ffmpeg. So, unless the OP needs to mux the current stream, my suggesrion stands.  
> **username_2**: I had the same issue as that post...I don't see it as being overly complicated.  That person attempted multiple things which made his post long and complicated, however.  As as you wrote in that thread, it played properly for you.  That poster said in his post that it did not play properly for him.  If it works for you, great.  However, I posted this answer based on my problem experience with fps and that other people who have posted here obviously had the same problem.  Also remuxing = copying video/audio stream into a different container.  So...I don't really follow your last sentence.  
> **username_3**: The OP here hasn't indicated that they need to stream copy. They just want a smoothly playing file that doesn't look "pretty crappy". Your 2nd option suggests ffmbc in order to remux the video stream. I suggested ffmpeg since it will be current (in terms of bugfixes and features).  
> **username_3**: What I meant by "complicated" in the case you cite is the problem there is not a generic bug of ffmpeg failing to preserve framerate during a MTS to MP4 remux but that when ffmpeg muxes a non-spec H264 interlaced stream with merged field pairs into an in-spec stream, thus separating each field, the frame rate analysis goes haywire. For this OP, that's not an issue since the 60fps mode in their camera only shoots progressive for which ffmpeg poses no problem.  
> **username_3**: I guess my chief objection was that your solution made it sound like ffmpeg can't handle MTS well, whereas it's that if you give it an *out-of-spec* H264 il stream to mux, the resulting file will show a wrong framerate. That's a niche case, not applicable to this OP and the preference for ffmbc not advisable in general.  

---

