[Matroska-devel] mkvalidator cluster/cues validation

msj 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.

/MSJ



"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).

Steve

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 
> this
> 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 
> flushing
> its buffers periodically and playback suffers.
>
> So the recommended way must be to keep the clusters at a reasonable size 
> say
> 512kb .. 1.5Mb and not necessarily align the clusters on video
> key-boundaries.
>
> The matroska format seems to be prepared for this approach via the
> CueBlockNumber so the mkvalidator warning, still makes little sense to
> me...
>
> Using the CueBlockNumber a player could easily skip the specified number 
> of
> blocks in order to find the "keyframe block" - and yes, its probably just 
> as
> easy without the CueBlockNumber information :-)
>
> /MSJ
>
>
>
> ----- 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.
>>
>> Steve
>>
>> 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 
>>> at
>>> the key-frame block. I could understand the warning if the
>>> CueBlockNumber element had not been present or was pointing at the wrong
>>> block.
>>>
>>> what seems to be missing from mkvalidator is a "cues key-validation" - 
>>> if
>>> 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
>>> seem
>>> 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
>>>
>>> /MSJ
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Matroska-devel mailing list
>>> Matroska-devel at lists.matroska.org
>>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>>> Read Matroska-Devel on GMane:
>>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>>>
>>
>>
>>
>> --
>> Steve Lhomme
>> Matroska association Chairman
>> _______________________________________________
>> Matroska-devel mailing list
>> Matroska-devel at lists.matroska.org
>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>> Read Matroska-Devel on GMane:
>> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>>
>
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane:
> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>



-- 
Steve Lhomme
Matroska association Chairman
_______________________________________________
Matroska-devel mailing list
Matroska-devel at lists.matroska.org
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: 
http://dir.gmane.org/gmane.comp.multimedia.matroska.devel






More information about the Matroska-devel mailing list