HandBrake

The simple solution is to demux the MKV (such as with MKVExtreact) then combine it with an MP4 muxer (such as Yamb), as long as the media types are compatible with the MP4 container.

One of the reasons I don't like using RF, for my purposes. Noisy/grainy pictures blow up file size like nothing else. If you do not mind re-encoding a couple of times, play around with lower quality RF settings and/or run a denoise filter, even the heavy one. You will lose detail, but it might be wo...

Oh yes, by "normal subtitles" I meant SRT. SubtitleEdit is spiffy, but I find it has massive issues with OCR on italics, which most subtitles have copious amounts of. For regular text it works perfectly, and the correcting features take care of minor problems. You may also want to take a l...

You might be trying to solve the wrong problem... PLEX clients can play regular subtitles just fine, no need to burn them in.

Either way, there is some speed to be gained by sacrificing file size, but generally a faster encode comes at the cost of lower quality, regardless of file size.

DVDs are encoded 720x400, so if they look fine on your 720p, they won't look any worse (or better) on a 1080.

Blu Rays are 1080 high, so I seriously doubt there are any "pros" to watching them on a 720 display.

I am surprised you can even buy a 50 inch that is 720.

This is an interesting phenomenon. Similar to compression in audio, which is supposed to, originally, make the compressed track "pop" over all the other ones on radio, and now people just expect it everywhere. Even I do for my movie playbacks, because it is more comfortable to set a volume...

Not sure whether this happens in .mp4 containers, but does in every .mkv I've made with Handbrake. I run my encode through Handbrake, then mux in .srt subtitles with MKVMergeGUI of mkvtoolnix, and end up, in every case as I said, with a SMALLER file. Always. By a few MBs mind you, no more than 1%, b...

I've been having an issue with some MKVs I've encoded recently, that have their subtitles changed when I include them as a stream during the Handbrake encode process. I can't attach files, so will try my best describe the problem. Subtitle entries with more than two lines appear to get collapsed int...

Still a bug? I am still getting it, but I am not sure whether this is just a problem with SRTs, I think it happens whenever any source (or destination?) filename contains a comma. Seems commas need to be escaped when external tools or whatnot are called, or maybe it is used as a separator somewhere?...