[FEATURE] mkv Support

[JRGonz]

It would be great to have the ability to convert (or copy) to mkv files. In the case of external subtitles: can ffmpeg detect external subtitles and faux the mkv as one file as well? (Meaning ffmpegts will treat an external .idx/.sub.ass/etc file as an mkv track when viewed by the user in the mounted directory?

[nschlia]

I have checked if MKV could work. Seems that I had some misconception of that format. It is to be closely related to WebM and actually is streamable, see: https://www.matroska.org/what_is_matroska.html. It was specifically designed with streaming in mind. Sorrry, that escaped me completly.

The problem is, like said, that MKV files have a header that is filled in by the FFmpeg API after the file was completely transcoded. I'll have to create a pro format header when transcoding starts. To figure that out may take some time, but should be possible.

So please be patient.

[nschlia]

Subtitle support is a completely different pair of shoes and not tied to MKV alone. TS and MP4 also support subtitles. This will be added dependently with #120.

[nschlia]

Checked the results created by the new MKV support. Interestingly, the files are accepted by VLC and MPV without problems. When comparing them with a hex editor, at the head of the files, there are some differences visible between the freshly created and finalised version.

Parsing them with libwebm's mkvparser_sample app reveals these differences:

Unfinished version:

        Duration        : 217873000000
        Duration(secs)      : 217.873
        Size(Segment)       : -1
                Simple Tag "DURATION" Value "(null)"
                Simple Tag "DURATION" Value "(null)"

Finalised version:

        Duration        : 220943000000
        Duration(secs)      : 220.943
        Size(Segment)       : 18419922
                Simple Tag "DURATION" Value "00:03:40.943000000"
                Simple Tag "DURATION" Value "00:03:37.834000000"

Video is reported 3:40.943 long, audio 3:37.834. This is possible. It seems the unfinalised version's duration field is approximately the audio duration. The segment size is -1 which means unknown. But this field could not be filled in anyway as the exact resulting size is actually unknown until the file had been finalised (I could set the predicted size, but that would probably rather hurt than do any good).

Out of curiosity I did the same check for the sister format webm, although there are binary differences also between on-th-fly and finalised version, mkvparser_sample reports the same result for both:

        Duration        : 217873000000
        Duration(secs)      : 217.873
        Size(Segment)       : -1

As webm works well I guess MKV could also be OK.