MKV vs MP4

[kingy444 117]

Now i understand these are just containers, and have scripted the conversion of that container for some time now (MKV -> MP4) purely for the compatibility & consistency. I've been doing this since xbox 360 days, and i'm starting to think that like when i made the move from avi -> mp4 its now time to move from mp4 -> mkv as my standard.

 

Just wanting some advice/opinions on this really. One part that had me wondering is an extract from the subtitles part of emby dashboard

Keeping text versions of subtitles will result in more efficient delivery and decrease the likelihood of video transcoding

With more and more shows requiring 'non-english' parts, I'm noticing I'm losing those subtitles that are part of the MKV already.

 

So i wanted to start a conversation on whether i am better to move to mkv as a standard or keep using mkv, and also script the extract of the srt file from the mkv as part of the container conversion?

 

One thing i don't like with MKV is that most embedded subs seem to be 'unk' language (obviously not emby's fault, im just ocd about this stuff), so i'll likely have to find someway to script that correction too)

 

What are others thoughts etc. and devs opinion on the best way to manage this?

[Luke 42079]

Both containers are good choices. Mp4 is best of all in terms of compatibility.

[kingy444 117]

Both containers are good choices. Mp4 is best of all in terms of compatibility.

 

If you had a show that required subtitles are you better off using mkv with the embedded subtitles or mp4 and external? I assume both work fine with the sync to device options?

 

One thing if i look to do mkv -> mp4 + external sub, whats your thoughts on the way auto organize should handle subs? at the moment it only processes video files, but if it can recognise the subtitle file for an episode than should it be organised too?

[MndWrp 101]

On a side note from the subs, its pretty easy to edit data in mkv containers without having to reencode or even remux. Things like chapter names, track names, track languages, internal flags etc... can be corrected in 2 seconds.

 

I'm no expert (meaning I'm not sure if this can be done to mp4 as well) but in my case that ease of use made me go mp4 -> mkv a long time ago.

 

Sent from my SM-G920W8 using Tapatalk

[MndWrp 101]

And as far as subs go, i always do external srt. It loads instantly in any app and if you happen to see typos in there, it takes a minute to fix and you don't have to reembed them in you video files after the fix... Just hit save.

 

Sent from my SM-G920W8 using Tapatalk

[Luke 42079]

I would use mp4 with external because the subtitles can be accessed directly from the file.

[mandysdad 30]

Both containers are good choices. Mp4 is best of all in terms of compatibility.

I have both in my library, although most are mp4, because some of the mkv files won't play correctly, something with the sound. Convert to mp4 and all works.

[Waldonnis 148]

Both containers have drawbacks.  Matroska (mkv) isn't as widely supported as mp4 when it comes to playback/devices, but can hold some codecs that mp4 cannot (mostly audio; I'm sure you can find a list on the web rather easily).  It really depends on what you want to store in the container and what you need in a container feature-wise.  Neither is necessarily better than the other until you run into situations where you really need one over the other.  Personally, I use both depending on what I'm doing, where/how it's being played, and what codecs I need it to contain....but Matroska is my go-to container most of the time due to its flexibility and the myriad of tools available to manipulate the files (nothing against mp4box, but MKVToolnix's command line tools are easier to deal with for me).  It's not without it's faults, though, and there are situations/scenarios where mp4 is really the only decent choice (friggin Apple...).

 

I'd say go with what you're comfortable with.  If you find that your container choice isn't working out for whatever reason, it's easy enough to remux them via a script.  Also, there's no need to really stick to either, so if you have a one-off situation where mp4 doesn't workout for that file, just use mkv instead for it.

 

As for languages, track default flags, etc in MKV files, check out the header editor in MKVToolNix's GUI as others have noted above.  There are also command-line tools included with it so you can script any change that the GUI can do.

Edited May 20, 2018 by Waldonnis

[jachin99 88]

mp4 is better for mobile viewing but MKV looks and sounds better.  I'm not even sure if 5.1 surround is supported in mp4 but I might be wrong.

[tman 47]

Back in the day, everything I converted was to MKV, and while it served me well, for the last couple of years, I've been using MP4. It works perfectly, is compatible with all the devices I have, and supports either AAC of passthrough DTS, which is what I mostly use. Quality is very, very good - even high bitrate 720P is often stunning. No problems here with 5.1 or 7.1 audio in an MP4 container either.

[mandysdad 30]

I have had a few mkv files that would not play to my roku.  I re encoded to mp4, leaving the sound as it was, and everything works. 5.1 sound and all. 

[Waldonnis 148]

I have had a few mkv files that would not play to my roku.  I re encoded to mp4, leaving the sound as it was, and everything works. 5.1 sound and all. 

 

I'd be curious to see a mkv file that won't play on a Roku.  Unless it's using features of the container that Roku doesn't support (e.g. linking) or the container-level data is corrupted, it should be fine.  The only other exception that I can think of is if it contains more than one video track, but that's a limitation of the Roku OS rather than a container issue.

 

To expand a tad on audio support, mp4 cannot hold TrueHD or PCM audio, so if your files include those codecs, Matroska is the only choice for those (of those two containers).  AC3/EAC3 and the DTS variants are okay in either, though.  I don't think mp4 can hold subrip (SRT) or ASS subtitles either, but it's been a while since I looked at container subtitle support so I could be mistaken.