Converting between .mkv .mov and .mp4

Question

I have been given some h264 video files in .mkv format and am able to convert these to .mov by resaving them out to .mov from QuickTime Player 7.
I can change the file extension in Finder to .mp4 and they seem to then more or less behave as .mp4 files.
Are they actually .mp4, or QT doesn't care and just opens them anyway?
What is the best method of handling these files for widest usage on multiple devices?
I have read up as much as I can on the file formats but no-where does it say what OSX is actually doing when I change the extension.
Am I right in wanting them to be .mp4 files?
Peter

Answer 1

I didn't state the audio format(s) because it has rarely been an issue, if it fails it fails at the first hurdle. The container.
Non-AAC audio will likely fail to load/play if the MKV Extension is changed at the Finder Level. Using MPEG Streamclip to move the compressed data to a "real" MP4 file container will normally strip the audio from the final file. If you wish to retain the audio, use the QT 7 Pro "Movie to MPEG-4" option, use video passthrough, and transcode the audio to AAC.
Most of the .mkv files have aac audio, but not all. Chapters are irrelevant, never having found any nor thought them useful.
This is a user preference. I prefer to keep the original chapter markers for apps that use them rather than falling back on the defaulted markers added by some device players.
I am playing the files on several Macs, 2 PCs, an iPhone, iPod Touch, iPad 2 and possibly future Android devices. There are even 2 TVs which seem to be stuck with only reading avi.
Macs, iPhones, iPod Touch, and iPad will play H.264/AAC compressed data natively in MOV, MP4, or M4v file containers. PCs and Android playback will depend on the compatibility of the player app used on the device. Macs will play H.264 with any audio supported by your Mac codec component configuration in the MOV file container.
My main target however is a PS3, which has turned out to be the most flexible media device in the house but does object to some files for indeterminant reasons. I will need to do comprehensive testing to find exactly what it is it doesn't like. Mostly it is good, once you update the system.
Do not own a PS3 but believe it is supossed to be compatible iTunes and mobile device supported formats. Again, the file container of choice would depend on the content you wish to include in the file. If you want to include AC3 DD5.1 sourround soud audio, I would normally recommend the MV4 or MOV containers.
The secondary target is iTunes so that I can get the files onto my iPod Touch and iPhone. I'm sort of used to that level of Apple devices (and I presume AppleTV) "Just not working" unless it suits Apple. So I restrict my viewing to mp4 files of my own creation or mkv files so over the top in size that recompression does little to degrade them.
Again, the M4V file container with H.264/AAC with or without AC3 surround audio, alternative AAC audio, and/or chapters is usually the preferred norm. If you plan to use a "universal" file format, then the display dimensions, frame rate, profile, and level for encodes may depend on the specific devices involved. I.e., that is why I limit my files to 720p30 Main Profile Level 3.1 to High Profile Level 4.0 compression and rarely use even half (more commonly only about a quarter to a third) of the video data rates allowed with these settings.
XBMC and other Media Server software seem, like VLC to be pretty tolerant, and whilst I haven't yet built myself a Media Server, it is on my longer term To-Do list.
I use iTunes for in-house media server software to TV and mobile devices with Air Video as my primary server software externally via the internet to mobile devices when away from home. Both access the same Promise Pegasus R6 12 TB RAID storage device. (Have moved most of my content from an old Drobo Pro RAID and am in the process of upgrading the current 16 TB unit to 24 TBs as individual drives fail for the storage of raw video footage.)
The h264 should pass straight through in a simple QT resave? Same if it has AAC audio?
If the source MKV file is playback compatible with your system's current codec component configuration, then the QT 7 Pro or MPEG Streamclip "Save As..." option can copy the data in the MKV file directly to a new MOV file container without transcoding/recompressing any of the data. Unfortunately, the QT X player is a bit more iffy. Basically, Apple has combined the "Save, Export, and Save As..." options in to a single menu option. The result is that sometimes the app will recompress the data and at other times it may not—dependent on a numbe of variables.)
If the MKV file contains H.264 video and AAC audio, then the MPEG Streamclip "Save As..." option allows you to select either MOV or MP4 as the target file container. If the MKV file contains H.264 video but the audio is not AAC but is still export-compatible with the QT 7 Pro app, then you can use the QT 7 Pro "Movie to MPEG-4" Export option to pass the H.264 video unchanged to a new MP4 file container while simultaneously coverting the audio to AAC. Since you still have not stated what non-AAC formats are included in some of your MKV files, I cannot tell at this point if this is a viable workflow for you.
That covers most cases. I'm still not a 100% clear on tghe real differences between .mov and .mp4 containers and how much it really matters in the scheme of things. .mp4 seems to the go, does .mov cause a problem? If so how and how best to rectify that?
The containers are different. They have different internal identifiers, features, capabilities, and sometimes limitations. CDs, DVDs, and BDs are all different types of optical media but each has different capacities, ratings, and features that determine how they can be used, what kind of media can be recoded on it, and what kind of a device must be used for playback. MP4 containers are very limited. Thay can only conatain MPEG-4 (MPEG-4/H.264) video and MPEG-4 (AAC) audio. M4V file containers are less limited and may typically contain H.264 video, AAC and/or AC3 audio, and chapter tracks. MOV file containers are generic and can hold up to 99 tracks of audio, video, image, text, 'tween, sprite, etc. data that is compatible with the system on which it was created. As to MOV files causing a problem—yes and no, depending on how you use it. Put "muxed" MPEG-2 data in an MOV file in an MOV file container and it will play normally in the QT 7 player (with the QT MPEG-2 component installed)—i.e., no problem. But try to play the same file in the QT X player and it will tell you that you are missing a codec component—a definite problem since you tried to play playable content in a container the media player did not expect to contain that particular form of compression. As to fixing aproblem. I would be better able to answer that if I knoew what specific problem you were referring to here.
This is why I keep harping about knowing which player is to be used, what audio and video compression format is being used and what container is to be used. And we have not even gotten around to checking the H.264 settings. QT based players are standards conscious. Each Profile and level combination tells the player the max macroblock decoding rate, number of macroblocks allowed per frame, the maximum video data rate allowed, the highest useable resolution @ the highest frame rate, what features are supported by profile, etc. Unfortunately, some third-party venders sometimes hybridize these settings which can make the files unplayable in QT apps but they may still play on other players which do not check on or trap on the use of non-standard settings.
BTW I did a quick hunt around on h265 and can't see what Apple is doing. Giving it a miss like it did with Bluray?
Apple is not known for embracing such technology quickly—especially since they are still drafting and reviewing drafted standards. (I believe DivX released a draft version on the 15th of this month.) The current evolution of QT X will probably take another 5-7 years and Apple will have to design hardware capable of handling 4K and 8K  if anyone is actually going to put it to use on future Mac systems. The development of mobile devices have, for the most part, only been supporting 1080p resolutions for a relatively short period and jumping to 8K would represent something of a quantum leap at the consumer level.