[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