[Cin] Cutting mkv causes video to stop at cut points

Andrea paz gamberucci.andrea at gmail.com
Thu Nov 24 10:26:35 CET 2022


>From the mkv documentation (https://matroska.org/technical/diagram.html):

"The Matroska EBML Schema defines eight Top Level Elements:

    SeekHead ((#seekhead)),
    Info ((#info)),
    Tracks ((#track-flags)),
    Chapters ((#chapters)),
    Cluster ((#block-structure)),
    Cues ((#cues)),
    Attachments ((#attachments-1)),
    and Tags ((#tags)).

The SeekHead Element (also known as MetaSeek) contains an index of Top
Level Elements locations within the Segment. Use of the SeekHead
Element is RECOMMENDED. Without a SeekHead Element, a Matroska parser
would have to search the entire file to find all of the other Top
Level Elements. This is due to Matroska’s flexible ordering
requirements; for instance, it is acceptable for the Chapters Element
to be stored after the Cluster Elements."

And this, too:

"The Cues Element is used to seek when playing back a file by
providing a temporal index for some of the Tracks. It is similar to
the SeekHead Element, but used for seeking to a specific time when
playing back the file. It is possible to seek without this element,
but it is much more difficult because a Matroska Reader would have to
‘hunt and peck’ through the file looking for the correct timestamp.

The Cues Element SHOULD contain at least one CuePoint Element. Each
CuePoint Element stores the position of the Cluster that contains the
BlockGroup or SimpleBlock Element. The timestamp is stored in the
CueTime Element and location is stored in the CueTrackPositions
Element.

The Cues Element is flexible. For instance, Cues Element can be used
to index every single timestamp of every Block or they can be indexed
selectively."


Instead, the ffmpeg documentation states.
(https://ffmpeg.org/ffmpeg-formats.html#matroska):

"reserve_index_space

    By default, this muxer writes the index for seeking (called cues
in Matroska terms) at the end of the file, because it cannot know in
advance how much space to leave for the index at the beginning of the
file. However for some use cases – e.g. streaming where seeking is
possible but slow – it is useful to put the index at the beginning of
the file.

    If this option is set to a non-zero value, the muxer will reserve
a given amount of space in the file header and then try to write the
cues there when the muxing finishes. If the reserved space does not
suffice, no Cues will be written, the file will be finalized and
writing the trailer will return an error. A safe size for most use
cases should be about 50kB per hour of video.
    Note that cues are only written if the output is seekable and this
option will have no effect if it is not.

cues_to_front

    If set, the muxer will write the index at the beginning of the
file by shifting the main data if necessary. This can be combined with
reserve_index_space in which case the data is only shifted if the
initially reserved space turns out to be insufficient.

    This option is ignored if the output is unseekable."

Perhaps one should indicate these parameters to CinGG?

PS: I did some tests (it had been a long time since I had used mkv)
without any problems, as also reported by IgorBeg.


More information about the Cin mailing list