Support for .mkv (or Matroska) Files with Write Access to remove Metadata

[ghost]

When will Exiftool support .mkv files, is it planned ?

As it is much popular as .mp4 it should be also taken into account.

Curently Exiftool Supports reading of Metadata in .mkv not removing metadata which needs write access.

[boardhead]

Sorry for the delay in responding -- I'm catching up now after my vacation.

There are currently no plans for implementing MKV write support.

[ghost]

But I think it must be implemented later sometime because now All Video Files are mostly encoded in Matroska Container Format.

Anyway waiting for it.

[boardhead]

In my experience, MP4 is by far the most common, followed by AVI and AVCHD, then MKV. So the ability to write AVI may have to be implemented before MKV. Also, the MKV metadata scheme is a real mess, so I don't look forward to working with this.

[ghost]

So, It is in the List very Far behind or removed from the list ?

[MasterInQuestion]

    Based on the context of a few posts that have gone missing asserting CFR (Constant Frame Rate) and superiority of MP4.

----

    MKV may be favored for having less restriction on the media formats (codecs) to contain.
    Any post-analog adequately designed container format (codec too) should be able to handle arbitrary frame rate (and VFR).
    For digital media, there's really no frame rate (nor time base [1]): only presentation timestamps (PTS).

    MP4 is far from the most optimal container format. (so is MKV) [4]
    For the typical application (local media playback), the container may not even be needed.

[ [1]
    For typical timestamp implementations: time base shouldn't be of concern.
    But when tailored to optimize for specific applications: time base may actually become a thing.

    Typical high-precision timestamps are based on Int64 and of a granularity of μs (i.e. 1/1,000,000 time base).
    Which should allow a max duration of (( (2^63 - 1) / 1,000,000 / (3,600 * 24) / 365.2425 ≈ 292,277 )) years in this configuration.
    .
    However support for granularity smaller than 1/10,000 may be pointless for common systems. (unreachable target accuracy for underlying system; due to beyond threshold latency [3]) [2]
    And using Int32 instead may provide relatively significant performance benefit in certain cases.
    .
    Thus an alternative configuration based on Int32 and of granularity of ms (1/1,000 s) is plausible:
    Which should still allow a max duration of (( (2^31 - 1) / 1,000 / (3,600 * 24) ≈ 24.8551348 )) days. (and max 1,000 FPS) ]

[ [2]
    Significant amount of audio handling are of 48,000 Hz. (1/48,000 < 1/10,000 indeed)
    But what handles the final audio playback is typically dedicated hardware (not software based on CPU [ Precisely, general purpose processors. ]).
    And which should load far more than 1 sample at once (more than 1 sample per frame), and is FIFO like.

    Note audio playback is somewhat different than video: the sample value (content) is uttered at the timestamp but not maintained across the whole duration. ]

[ [3]
    The system's latency may be estimated using `while ( 1 ) { printTS(); };` alike structure.
    E.g. in Bash:
[[

	x0="${EPOCHREALTIME%%.*}";
	while true;
	do {
	x1="$EPOCHREALTIME";
	x2="${x1%%.*}";
	[ "$x2" == "$x0" ] && continue;
	echo -E "$x1";
	x0="$x2";
	};
	done;
#
#	Less likely to work:
# [[
#	while true; do { [ "${EPOCHREALTIME##*.}" -eq 0 ] && echo -E "$EPOCHREALTIME"; }; done;
# ]]
#

]] ]

[ [4]
    Why exactly?
    MP4 had the information critical [1] for media playback stored at 1 location (usually near the end of file; or the start of file).
    Such design has caused some problems. [ See FFmpeg's documentation on related muxers. ]
    .
    Timestamps could be wrapped as part of each packet (encoded frame), thereby achieve superior performance meanwhile getting rid of all aforementioned problems.
    Such was somewhat done in MKV. But of significant overhead. (complicated "cues", and many more)

    More on the topic:
    https://github.com/MasterInQuestion/talk/discussions/3

[1] "moov atom", in MP4 terminology. Mostly contained the presentation timestamps, and frame dimensions. ]

    ----

    The ideal container format should be based on a general purpose container format: 7z should be a good start point.

[MasterInQuestion]

    https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Containers#mpeg-4_mp4

    The description covers more than just H.264: intended for all codecs (both audio/video) in general.
    It's a functional analysis on the underpinnings: whose validity is irrelevant of whether particular implementations work or not.

    Unnecessary elements may indeed exist (or even be required).
    But indeed they do not have to.

[mikethecalamity]

Any movement on this? MKV seems to be very prevalent now.

[boardhead]

No movement, but I'll add it to the top of my to-do list and we'll see if that helps. Generally significant additions like this will have to wait until the winter when I have more free time.