[Matroska-devel] mkvalidator cluster/cues validation
therealmsj at gmail.com
Wed Aug 17 19:48:36 CEST 2011
Yes, I tried that and ran into the problem of not being able to play all
mkv files perfectly.
Investigated the matter and found that by reducing the cluster-size to a
maximum of 512k-1Mb, the problem completely disappeared - as far as I
remember the critical cluster size was around 1.2-1.5MB/cluster.
Should be said that my own PC only has a AMD athlon 64X2 / 4200+ and a
"slow" green-WD HD.
Regarding the VLC player , maybe my conclusion is wrong but using the
"process explorer" and looking at the I/O bytes history it seems that
access to the file happens cluster-wise. With cluster size 1.5Mb , the I/O
history repeatedly shifts betwen zero and 1.5Mb, with 1 Mb cluster size -
between 0 and 1Mb. With cluster sizes limited by time (2 seconds) , a much
more contineous "I/O bytes history" appeared.
Anyway , compared my output with some mkv files generated by mkvmerge -
observed the same mkvalidator warnings - clusters seemed to be limited by
size / time, not necessarily aligned on video key frame boundaries. One of
the mkvmerge files I generated myself using latest mkvmerge with default
command line options.
mkvclean I have not yet tried.
"Steve Lhomme" <slhomme at matroska.org> wrote in message
news:CAOXsMFJuWk3=83RRVQeqgQtYEJtHhaE4UAhYMSCNyZdNPyBgrA at mail.gmail.com...
Have you tried the large Cluster approach ? That's what mkclean does
with --remux regardless of the Cluster and it works fine. I don't
think there are any player that loads a whole Cluster in memory
(although that's one of the original goal).
On Tue, Aug 16, 2011 at 6:22 PM, <michael.steen.jensen at tdcadsl.dk> wrote:
> Hi Steve
> Thanks for the reply.
> Just to explain:
> Could easily change my MKV muxer so the warnings disappears - aligning the
> clusters on video key-frame boundaries. However for highdef video files
> is likely to cause an even more serious problem than
> say slow seeking - namely that playing the file does not work properly. If
> the cluster size gets too big, players like VLC most likely ends up
> its buffers periodically and playback suffers.
> So the recommended way must be to keep the clusters at a reasonable size
> 512kb .. 1.5Mb and not necessarily align the clusters on video
> The matroska format seems to be prepared for this approach via the
> CueBlockNumber so the mkvalidator warning, still makes little sense to
> Using the CueBlockNumber a player could easily skip the specified number
> blocks in order to find the "keyframe block" - and yes, its probably just
> easy without the CueBlockNumber information :-)
> ----- Original Message ----- From: "Steve Lhomme" <slhomme at matroska.org>
> Newsgroups: gmane.comp.multimedia.matroska.devel
> To: "Discussion about the current and future development of Matroska"
> <matroska-devel at lists.matroska.org>
> Sent: Sunday, August 14, 2011 4:13 PM
> Subject: Re: mkvalidator cluster/cues validation
>> It is a warning because it's not optimal for seeking. A lot of data
>> will be read for nothing in this case, unless the Cluster is not
>> referenced in the Cues and if the Cues are not damaged.
>> I don't think there are much players that make use of the
>> CueBlockNumber element at all.
>> On Wed, Aug 3, 2011 at 9:20 AM, <therealmsj at gmail.com> wrote:
>>> mkvalidator complains about "first block for video track # not being a
>>> key-frame". Its only a warning but why complain about
>>> something thats totally valid - in this case the CueBlockNumber points
>>> the key-frame block. I could understand the warning if the
>>> CueBlockNumber element had not been present or was pointing at the wrong
>>> what seems to be missing from mkvalidator is a "cues key-validation" -
>>> the first block is not a video key-frame and CueBlockNumber is not
>>> present it should generate a warning. A warning because there does not
>>> to be any requirement that cues should only contain references
>>> to key-frames. Also, mkvalidator seems to ignore the CueBlockNumber -
>>> writing a wrong block number does not generate any error.
>>> please comment.
>>> Thanks in advance
>>> Matroska-devel mailing list
>>> Matroska-devel at lists.matroska.org
>>> Read Matroska-Devel on GMane:
>> Steve Lhomme
>> Matroska association Chairman
>> Matroska-devel mailing list
>> Matroska-devel at lists.matroska.org
>> Read Matroska-Devel on GMane:
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> Read Matroska-Devel on GMane:
Matroska association Chairman
Matroska-devel mailing list
Matroska-devel at lists.matroska.org
Read Matroska-Devel on GMane:
More information about the Matroska-devel