I'm a so freaking pissed. I've been trying to convert a 720p MKV video file to a 720p MP4 file with NO video quality loss. I've been trying to do this for ALMOST A WEEK with no luck. All these threads go on about "demux" then you "remux" then you whatever "mux" ughhh!! I have no idea what any of that means. They then go on about having to do some crazy stuff in terminal with a program called MP4Box, I have no idea what that does or how to use it, what so ever.

Instead of spending weeks on trying to convert these damn 720p video files, isn't there a program that I can just drag the file onto, set it to MP4 and get my file with no quality loss?!?!

I do a fair amount of MKV to MP4 conversion and have found Handbrake to do an adequate job. Keep in mind most of the MKV files are large HD files that I am converting from Make MKV for Apple TV but tweaking the quality settings has provided very high quality (albeit somewhat large) MP4 files in my iTunes library.

For my purposes the new Handbrake settings for the Apple TV 3 seem to be pretty good ... although I need to do some in depth testing to verify my initial impressions.

I do a fair amount of MKV to MP4 conversion and have found Handbrake to do an adequate job. Keep in mind most of the MKV files are large HD files that I am converting from Make MKV for Apple TV but tweaking the quality settings has provided very high quality (albeit somewhat large) MP4 files in my iTunes library.

For my purposes the new Handbrake settings for the Apple TV 3 seem to be pretty good ... although I need to do some in depth testing to verify my initial impressions.

Hope this helps.

Ah ok, I'm converting this to MP4 so that I can burn it to a DVD using Toast, which will create a HD-DVD. It'll be played on a 50" Television so I need to retain the quality!

Instead of spending weeks on trying to convert these damn 720p video files, isn't there a program that I can just drag the file onto, set it to MP4 and get my file with no quality loss?!?!

PLEASE HELP ME SOMEONE, THIS IS DRIVING ME FREAKING INSANE.

Well that all depends on what type of video stream is in the mkv files you're trying to remux, as long as the video stream is compatible with the device you're trying to play it back on than remuxing should be easy. I suggest iFlicks, just drag your mkv file into it set the convert option to "iTunes compatible" and as long as the video stream is iTunes compliant it will remux the file in just a few minutes with no loss of quality, however if the video stream isn't compatible then you **** out of luck and a full reencode will be needed and I'm afraid that takes time, and you'll more than likely lose some quality.

Edit:-

Quote:

Originally Posted by javilionaire

Ah ok, I'm converting this to MP4 so that I can burn it to a DVD using Toast, which will create a HD-DVD. It'll be played on a 50" Television so I need to retain the quality!

Well scratch all that, as you didn't specify, I assumed you wanted a mp4 file to play back in iTUnes or on an iOS device.

u people have too much time to waste. go buy a media player ($100 or so) capable of mkv playback and your problems are solved.

I had a media player. Slow w large libraries, clunky interface, full of bugs and no longer supported with new FW. Also spent more time trying to correct it's errors on categorizing my files and scraping metadata.

There is no reasonably priced media player that does it all. You have to go HTPC to get it all. For $99 I'm happy as a pig in mud!!!!

But depending on the proximity, that can tie up the computer while the movie is playing. I used to do that and probably will do it again when it's important to me to watch that uncompressed source file.

I haven't seen any airplay (from an iPad) or AirParrot streaming yet that is as good as the aTV or direct MBP connection.

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.

Software
Quicktime 7 Pro
Perian

Process
- Install the necessary software

- Open the MKV file in Quicktime 7 Pro

- It may take a few minutes depending on the length to open (you will see the progress above the play button) - perian is working in the background to get quicktime to read the mkv

- Once the file is open and you can play it in Quicktime 7 Pro go to - FILE --> EXPORT... (drop down menu)

- In the 'EXPORT' dropdown menu select "Movie to MPEG-4"

- Click 'OPTIONS'

- In the video Format dropdown menu select 'PASS THROUGH'

- You may set your own audio/streaming options to your liking, then click "OK"

- Click "SAVE"

- The file will then save your new video file in the MP4 container without re-encoding the original video component saving substantial time & processing.

But depending on the proximity, that can tie up the computer while the movie is playing. I used to do that and probably will do it again when it's important to me to watch that uncompressed source file.

I know. But I find that I'm also tied up when the movie is playing. Watching the movie.

this is a great thread. many of the tools i am familiar with are windows based, because i rarely need to deal with containers since getting a mac. it's useful to know about these tools when for when i need them. thanks to op and all the comments.

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".

__________________
10 Macs, including the first 128K Mac and a late-2011 MBA, 7 iPods, 2 iPhones, iPad 1, iPad 3, and lord knows how much Apple software over the years.

...All these threads go on about "demux" then you "remux" then you whatever "mux" ughhh!! I have no idea what any of that means...

This is easily explained, if you care. "Multiplexing" refers to combining more than one data stream together into a single data stream. "Demultiplexing" refers to parsing certain elemental data streams out of a stream that contains multiple data streams (was originally multiplexed), where some of the elemental streams get passed on in the workflow while some are discarded. "Remultiplexing" refers to multiplexing (actually means the same thing) but to putting together elemental streams that were either once previously multiplexed and later demultiplexed, or combining the streams of interest from that workflow with new streams into a single MPTS or Multiple Program Transport Stream.

And "mux" is short for "multiplex". Taken as a whole it refers to the chemistry of taking digital data streams apart and combining them.

In the consumer world, a common form of demux would be to take a DVD which has streams for audio, video, second audio, secondary programs (such as outakes or attached documentaries) and during a rip, parsing out the stuff you don't really need so that you are left with just the main audio and video, which can make the file size smaller and therefore manageable and portable.

A common form of remux would be if you shoot your own home video and then add descriptive metadata, captions, or a program description to the edited audio and video, so that all of that is in one program stream or transport stream file.

The trick is to realize that all of that is separate from the question of transcoding issues, even though they commonly are done at the same time. You don't have to understand or even use multiplexing techniques to achieve a rip or a transcode. You can learn as much or as little of each as you want to, without really affecting your understanding of the other. You don't have to understand it all as one big ball of stuff; you can compartmentalize, which magically removes all fear and intimidation.

The entire secret of understanding technology is that all complex issues can be broken down into smaller, less-complex components. conquer or understand the pieces separately, each on its own turf, then you can much more easily understand the whole.

__________________
10 Macs, including the first 128K Mac and a late-2011 MBA, 7 iPods, 2 iPhones, iPad 1, iPad 3, and lord knows how much Apple software over the years.