[mythtv-users] Should I prefer mp4 or mkv in Handbrake output?

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Sat Sep 20 21:29:30 UTC 2014


    > Date: Sat, 20 Sep 2014 15:16:06 -0400
    > From: "Peter Bennett (cats22)" <cats22 at comcast.net>

    > My own limited experience showed it to be preferable to use mkv. The
    > mkvtoolnix tools work better than the mp4 tools. Handbrake is able to
    > include subtitles in the mkv file, not sure if it can do that with mp4

Ah, that's an interesting point.  I currently save captions from
PVR-x50 recordings in plain text via some ancient code from almost 10
years ago (not ccextractor)---but that data can also be converted from
the plaintext format into SRT via a perl tool, which I assume I can
then inhale into an MKV.

    > files. I also found that Handbrake encoding to mp4 resulted in files
    > that were unplayable on a DVD player, while encoding to mkv and then
    > using a patched avconv to copy convert the mkv to mp4 gave a file that
    > was playable on the DVD player. mkv was not directly playable on the DVD
    > player.

Good to know, though not my use case.

    > Using mythcommflag on the mkv file works and actually deletes the seek
    > table. It is necessary to do this, if the seek table is present, seeking
    > does not work. After this, seeking works fine on the mkv files.

Oh, interesting!  So an MP4 in an MKV means that I'm not storing a
huge seektable for each file?  (This matters in my case, since I have
many, and recordedmarkup is by far the largest part of my database,
which makes the whole thing a bit unwieldy.)  I assume this means that
Myth is only storing the jump points from commflagging in the DB
(e.g., half a dozen records per recording, instead of thousands),
or perhaps in the MKV file itself?

Thanks; this is all good to know.  Sounds like I should be generating
MKV's and not MP4's.


More information about the mythtv-users mailing list