MKV can be a little confusing, but converting it to MP4 can be relatively painless and quick if you use the right tools and options.
Background Info
MP4, MOV and MKV are all container files. Think of them like a lunch box. Within these go your video (with it's own codec) and audio, think of these to be your lunch that goes in the lunch box. If you have a device (in this case ATV) that can ingest the codec but not the container than you should not re-encode it. You should use the "PASS THROUGH" option which takes the codec (h.264, xvid, etc.) and puts in another container (MP4). Re-encoding it would take the codec and re-process it (in this analogy it would first take apart your sandwich and then re-assemble it before putting in the new lunchbox) so you want to avoid this if the codec is compatible with the device you wish to watch it on. Passing through the codec takes only as long as re-copying the file to the hard drive, whereas re-encoding it can take many hours to days depending on the file size and options...
I love your lunchbox analogy.
The first problem here is that mp4 and mks refer to the containers (as you indicated) and not the codec inside, and therefore somewhat en-veil what is really within. While mp4 containers can contain files encoded in a half-dozen different codecs, mkv containers are compatible with just about any codec, and that can imply a possible incompatibility
depending specifically on the target decoder, all of which may or may not imply a re-encode within the workflow.
This means that the question then becomes, continuing your analogy, "how do I convert what is inside lunchbox A to what should be inside lunchbox B
so that it will be compatible with the target decoder and player?", which is really the same question, only it points out how uncontrollably vague the question really is, and how it does not provide all of the specifications needed to allow a definitive answer to the question because the terms mkv and mp4 are somewhat ambiguous as to what codecs they might contain.
IOW, from simply identifying the lunchboxes or containers we don't know exactly what codec is inside the source container and whether the destination player will require it to be re-encoded into what codec it expects to be within the target or destination container, or not. Knowing the container formats is just not enough information on its own.
The good news is that the common answers are usually that what is encoded is also the same thing that (or compatible with what) the target player expects, and all that is needed to convert is to rewrap the existing source codec in the new container format. That would usually be quick and painless and not imply any generational quality loss.
The bad news is that possibly (but rarely) the target player expects a codec different than the one in the original wrapper, and therefore the workflow invokes a re-encode, and that may imply a slower process with some generational losses. It depends.
And just trying to identify that by the wrapper formats doesn't really answer that question; mp4 to mkv or
vice versa might mean a re-encode in one workflow, and it might not in another, depending on what the source codec is (which we can't discern from the source wrapper) and what the target decoder expects (which we also can't discern from the target wrapper).
And when you resort to 3rd-party software this opens up an entirely new can of worms, which is
the second problem. The critical thing is does the transcode software (which must identify both the source and destination codecs as well as the wrapper formats) really understand what the destination decoder/player actually requires? Its definition of mp4 as a target is arbitrary and the codec it chooses might not match exactly what is needed for a particular workflow also defined by that same ambiguous container format. It might arbitrarily re-encode or not re-encode, simply because that company is completely divorced from the target decoder/player, and the choices for what codec they choose for a particular transcode are made by the creator of Handbrake, two continents and an ocean away, instead of by Apple, for instance.
Handbrake can't read the mind of an iPad; it has no intrinsic knowledge of what the iPad expects, based on just the identification of the container format. If Handbrake works, that is either completely by accident, nothing more than coincidence, or some French Handbrake engineer took the time to specifically massage it to work directly with the iPad. We hope one or the other happened; we just don't really know if either of them did until we try Handbrake, or iFlicks, or whatever.
So whether one tool or another will work for a particular workflow, especially one vaguely described by just the container formats, is basically a crap shoot. You might get a legitimate mp4 to mkv conversion with one tool that invokes a re-encode that you never really needed, and you pay the price in time and quality, even if that tool specifically states that this particular transcode will be compatible with a particular device. Or you may get a legitimate conversion with a different tool that does not choose to do a re-encode at all, but when you go to play it back, nothing happens. The target container format matches, but the target codec might still not be compatible. You wont really know until you try. All of this implies that
you should try "passthrough" first. If that doesn't work, try something else.
The only practical way to deal with this is to try what folks who have blazed their part of the trail suggest until you find what works for your particular situation, because there is no guarantee that your particular workflow is the same as someone else's; the target encoder may be different and the source codec may be different, even if both workflows are described by "mp4 to mkv".
