Subject: Re: [Cellar] Matroska Ordering Guidelines

From: Dave Rice <[email-masked]>
Date: Wed, 18 May 2016 23:08:13 -0400

> On Feb 27, 2016, at 4:02 PM, Dave Rice <[email-masked]> wrote:
> 
> Hi all,
> I'm reviewing the documentation at https://matroska.org/technical/order/index.html <https://matroska.org/technical/order/index.html> and have some questions and comments.
> 
> The Order Guidelines say
>> Matroska only needs a few level 1 elements to be playable: Segment Info, Track Info, Clusters. These elements have to be present in a Matroska file.
> 
> However, the specdata.xml lists Info as the only mandatory Level 1 Matroska Element. From specdata.xml it appears that a Matroska can be valid even without Tracks or Clusters Level 1 Elements. So are Level 1 Track and Cluster elements mandatory or not. Should there be a distinction between a “playable Matroska” and a “non-playable Matroksa”?
> 
> This sentence:
>> All the other elements can be omitted although Cues (index) improve the playback experience greatly.
> 
> seems far too broad. I suspect that it should be "All the other Level 1 elements...".
> 
> Regarding,
>> After a Matroska file has been created it may still be edited. For example chapters, tags or cover art attachments can be added. To do that the Meta Seek needs to be updated and also some elements may be voided or extended.
> 
> These sentences imply that if Chapters, Tags, or Attachments are aded then MetaSeek is mandatory, but is this true? Also IIRC MetaSeek doesn't need to reference all Level 1 elements, so Attachments could be added without creating or updating MetaSeek?
> 
> Regarding,
>> When 1 Meta Seek Head is present, it should be the first element in a Segment…
> 
> Is this true? If MetaSeek is present a MetaSeek element MUST be the first element of the Segment? This conflicts with the rules for CRC which must also be first.
> 
> Regarding:
>> The second Meta Seek is placed at the end and contains a lengthy list of all Clusters (and not the other level 1 elements).
> 
> To clarify if a second MetaSeek is used under Segment than it must be the last element of the Segment? If the second MetaSeek is used it can only reference Clusters and not any other level 1 element? I thought that a second MetaSeek could be used to list any other type of level 1 element that didn't fit in the first existing MetaSeek to avoid rewrites. Which is true? Also is a third or greater MetaSeek element ever allowed?
> 
> Regarding
>> Placing the first Meta Seek Head other than the first position of the Segment would make it a lot less useful So it <em>must</em> be the first element of a Cluster.
> 
> I think this should read "be the first element of a Cluster”, right?
> 
> Regarding:
>> So the Cues <em>should</em> always be written after the Clusters. However the <a href="#cues_front">Cues could also appear at the front</a>.
> 
> I'm confused by the way this is written. In what cases should Cues be written before or after Cluster?
> 
> Overall the documentation seems to suggest that multiple different elements all belong at the "end". Does the "end" mean "the last Level 1 element" or simply "after the last Cluster element”?

Now that the Matroska Ordering Guidelines is in the matroska-specification repo, I wrote a pull request to update the existing documentation to use the vocabulary style of the EBML specification. This is probably most easily reviewed in this layout on GitHub https://github.com/Matroska-Org/matroska-specification/pull/11/files?short_path=e54a0c6#diff-e54a0c68b10a172d7d578cd64ffbbc82 <https://github.com/Matroska-Org/matroska-specification/pull/11/files?short_path=e54a0c6#diff-e54a0c68b10a172d7d578cd64ffbbc82> though this view is also available https://github.com/Matroska-Org/matroska-specification/pull/11/files <https://github.com/Matroska-Org/matroska-specification/pull/11/files>. To summarize I capitalized ‘Element’ as tilde-quoted the Element names. I also changed reference to Level 1 Elements to “Top-Level Elements” which is specifically defined in the EBML Specification.

The SeekHead Element is often referred to as “Meta Seek”, I changed much of this to SeekHead, but is there a preference or distinction between these two terms?

Dave Rice

---

From: Dave Rice <[email-masked]>
Date: Mon, 23 May 2016 23:07:07 -0400

Hi all,

> On May 18, 2016, at 11:08 PM, Dave Rice <[email-masked]> wrote:
> 
>> 
>> On Feb 27, 2016, at 4:02 PM, Dave Rice <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi all,

I started a rewrite of the Matroska Ordering Guideilnes in order to correct and clarify the recommendations and mandates of the section. I’ll include the updated text below and it is also reviewable as a pull request at https://github.com/Matroska-Org/matroska-specification/pull/16. Because this is a rewrite, it is difficult to diff, but please review what parts are deleted. This link is probably the most readable diff: https://github.com/Matroska-Org/matroska-specification/pull/16/commits/9fd95b3a0ad75ee49ac56b9f09efbebb7c08f1e3. Overall I’ve intended to keep the same meaning but form it more clearly, but this needs a review.

In addition to a rewrite I added a few more recommendations or mandates which include:

- "The Matroska specification recommends that `CRC-32` Elements SHOULD NOT be used as an immediate Child Element of the `Segment` Element”. The EBML spec permits CRC-32 within Level 0 Elements and I’ve seen files before with CRC-32 as a Child Element of the EBML Header.

The `Info` Element doesn’t have it’s own ordering suggestions but the `Chapters` Element section infers it, so I added an `Info` ordering section based on what is inferred.

I removed use of gendered pronouns about the user.

Some questions:

I’m confused about the mandates of referencing `Clusters` in `SeekHead`. Is it required that ALL Cluster are referenced by the `SeekHead` Element(s)? Or is only the first Cluster a mandate and the rest of the Clusters suggested? If two `SeekHead` Elements are used, is the first `SeekHead` allowed to reference all `Cluster` Element?

The EBML specification gives a distinction between Level 1 Elements and Top-Level Elements in that Top-Level Elements are Elements that may only occur at Level 1. Thus CRC-32 and Void (as global elements) are not considered Top-Level Elements. If Void and CRC-32 are used at Level 1, is it clear that these Elements do not have to be referenced in the SeekHead Element(s)?

I’m also realizing that in the EBML specification we should clarify that the Child Elements of the EBML Header are not considered Top-Level Elements even though they are defined only at Level 1.

I’d like to verify that it is a requirement that the second `SeekHead`, if used, only contain reference to `Cluster` Elements. For instance if the first `SeekHead` is not followed by some padding, then this requirement makes it difficult to edit a file (to add an attachment, tags, or chapters) without re-writing most of it.

We should recommend a certain amount of padding to follow the first SeekHead. Any recommendations?

The recommendations about the `Cues` Element placement seemed contradictory (should be at the end, but could be at the beginning), so I revised this a bit. However I think this section should more clearly explain the advantages and disadvantages of storing the Cues Element near the beginning or near the end. Any advice?

Any existing good documentation on Ordered Chapters?

The Tags ordering section suggests that if a Tags Element is at the beginning of the file and needs to be edited/expanded, then the Tags Element can be Voided, and a new one written at the end. But the Tags Element is allowed to occur multiple times. If someone is just added a new tag, could the new Tags Element just be written at the end of the Segment and the first Tags element left as is?

And now here’s a darft rewrite of the section on ordering requirements within Matroska:

---
layout: default
---
Except for the EBML Header and the CRC-32 Element, the EBML specification does not require any particular storage order for Elements. The Matroska specification however defines mandates and recommendations for the ordering certain Elements in order facilitate better playback, seeking, and editing efficiency. This section describes and offers rationale for ordering requirements and recommendations for Matroska.

# Top-Level Elements

A valid Matroska file requires only one Top-Level Element, the `Info` Element; however, to be playable Matroska MUST also contain at least one `Tracks` and `Cluster` Element. The first `Info` Element and the first `Tracks` Element MUST either be stored before the first `Cluster` Element or both be referenced by a `SeekHead` Element which occurs before the first `Cluster` Element.

After a Matroska file has been created it may still be edited. For example chapters, tags or attachments may be added. When new Top-Level Elements are added to a Matroska file the `SeekHead` Element(s) MUST be updated so that the `SeekHead` Element(s) itemize the identify and position of all Top-Level Elements. Editing, removing, or adding Elements to a Matroska file often requires that some existing Elements be voided or extended; therefore, it is recommended to use Void Elements as padding in between Top-Level Elements.

# CRC-32

As noted by the EBML specification, if a <a href="https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown">`CRC-32` Element</a> is used then the `CRC-32` Element MUST be the first ordered Element within its Parent Element. The Matroska specification recommends that `CRC-32` Elements SHOULD NOT be used as an immediate Child Element of the `Segment` Element; however all Top-Level Elements of an EBML Document SHOULD include a CRC-32 Element as a Child Element.

## SeekHead

If used, the first `SeekHead` Element SHOULD be the first non-`CRC-32` Child Element of the `Segment` Element. If a second `SeekHead` Element is used then the first `SeekHead` MUST reference the identity and position of the second `SeekHead`, the second `SeekHead` MUST only reference `Cluster` Elements and not any other Top-Level Element, and the second `SeekHead` MAY be stored in any order relative to the other Top-Level Elements. Whether one or two `SeekHead` Elements is used, the `SeekHead` Element(s) MUST reference the identify and position of all Top-Level Elements except for the first `SeekHead`.

It is recommended that the first `SeekHead` Element be followed by some padding (a `Void` Element) to allow for the `SeekHead` Element to be expanded to cover new Top-Level Elements that may be added to the Matroska file, such as `Tags`, `Chapters` and `Attachments` Elements.

## Cues (index)

The `Cues` Element is recommended to optimize seeking access in Matroska. It is programmatically simpler to add the `Cues` Element after all of the `Cluster` Elements are written because this does not require a prediction of how much space to reserve before writing the `Cluster` Elements. On the other hand, storing the `Cues` Element before the `Clusters` can provide some seeking advantages.

## Info

The first `Info` Element SHOULD occur before the first `Tracks` and first `Cluster` Element.

## Chapters

The `Chapters` Element SHOULD be placed before the `Cluster` Element(s). The `Chapters` Element can be used during playback even if the user doesn't need to seek. It immediately gives the user information of what section is being read and what other sections are available. In the case of Ordered Chapters it recommended to evaluate the logical linking even before starting playing anything. The `Chapters` Element SHOULD be placed before the first `Tracks` Element and after the first `Info` Element.

## Attachments

The `Attachments` Element is not meant to use by default when playing the file, but may contain the cover art and/or fonts. Cover art is useful even before the file is played and fonts may be needed before playback starts for initialization of subtitles that may use them. The `Attachments` Element MAY be placed before the first `Cluster` Element; however if the `Attachments` Element is likely to be edited, then it SHOULD be placed after the last `Cluster` Element.

## Tags

The `Tags` Element is the one that is most subject to changes after the file was originally created. So for easier editing the `Tags` Element SHOULD be placed at the end of the `Segment` Element, even after the `Attachments` Element. On the other hand, it is inconvenient to have to seek in the `Segment` for tags especially for network streams. So it's better if the `Tags` Element(s) are found early in the stream. When editing the `Tags` Element(s), the original `Tags` Element at the beginning can be <a href="/technical/specs/index.html#void">voided</a> and a new one <a href="#tags_end">written right at the end</a> of the `Segment` Element. The file size will only marginally change.

## Optimum layout from a muxer

* SeekHead
* Info
* Tracks
* Chapters
* Attachments
* Tags
* Clusters
* Cues

## Optimum layout after editing tags

* SeekHead
* Info
* Tracks
* Chapters
* Attachments
* Void
* Clusters
* Cues
* Tags

## Optimum layout with Cues at the front
* SeekHead
* Info
* Tracks
* Chapters
* Attachments
* Tags
* Cues
* Clusters

# Cluster Timecode

As each `BlockGroup` and `SimpleBlock` of a `Cluster` Element needs the Cluster `Timecode`, the `Timecode` Element MUST occur as the first Child Element within the `Cluster` Element.

Comments welcome in this thread of in the pull request, such as line comments on https://github.com/Matroska-Org/matroska-specification/pull/16/commits/9fd95b3a0ad75ee49ac56b9f09efbebb7c08f1e3.

Best Regards,
Dave Rice

---

From: Moritz Bunkus <[email-masked]>
Date: Tue, 24 May 2016 09:18:03 +0200

Hey,

> - "The Matroska specification recommends that `CRC-32` Elements SHOULD
>   NOT be used as an immediate Child Element of the `Segment`
>   Element”. The EBML spec permits CRC-32 within Level 0 Elements and
>   I’ve seen files before with CRC-32 as a Child Element of the EBML
>   Header.

I'd like to keep the wording "SHOULD NOT … as a child of … segment" for
several reasons:

- If such an element is present updating any part of the file (changing
  header values, adding attachments, removing chapters…) requires
  re-calculating the CRC-32 element.
- Verifying the element requires reading the whole file which requires a
  lot of time and resources.
- It doesn't provide a lot of value. If it is invalid all you can say is
  that the whole, arbitrarily large file is damaged somewhere. With
  libEBML you cannot even verify the CRC-32 properly because it requires
  the whole element to be present in memory at the moment…

> The `Info` Element doesn’t have it’s own ordering suggestions but the
> `Chapters` Element section infers it, so I added an `Info` ordering
> section based on what is inferred.

Sounds fine.

> I’m confused about the mandates of referencing `Clusters` in
> `SeekHead`. Is it required that ALL Cluster are referenced by the
> `SeekHead` Element(s)?

No, we never mandated that. It doesn't provide much value over having
`Cues` elements anyway. I prefer guidelines to reflect what works well
in practice, and in practice you don't need `Clusters` to be referenced
by `SeekHead` elements.

> Or is only the first Cluster a mandate and the rest of the Clusters
> suggested? If two `SeekHead` Elements are used, is the first
> `SeekHead` allowed to reference all `Cluster` Element?

Additionally I don't see any benefit of restricting which `SeekHead` can
contain the clusters seeing how little benefit referencing the clusters
provides.

In fact I don't like imposing real restrictions on where to reference
elements from. If a player can read `SeekHead` elements then it should
not matter which `SeekHead` references which element – the player should
process them all.

Now from a perspective of being able to edit the file after it's been
created putting most content into a `SeekHead` at the end of the file is
more sensible as an editor has much more options to deal with such a
structure than if they're all part of the first `SeekHead` at the front
of the file.

> The EBML specification gives a distinction between Level 1 Elements
> and Top-Level Elements in that Top-Level Elements are Elements that
> may only occur at Level 1. Thus CRC-32 and Void (as global elements)
> are not considered Top-Level Elements. If Void and CRC-32 are used at
> Level 1, is it clear that these Elements do not have to be referenced
> in the SeekHead Element(s)?

Huh… Interesting question. As they're not required for playback I don't
consider them to be candidates for mandatory referencing; though it is
obvious that knowing their location is beneficial for certain kinds of
applications (CRC-32: structure verification & editing; Voids: editing).

> I’d like to verify that it is a requirement that the second
> `SeekHead`, if used, only contain reference to `Cluster` Elements. For
> instance if the first `SeekHead` is not followed by some padding, then
> this requirement makes it difficult to edit a file (to add an
> attachment, tags, or chapters) without re-writing most of it.

I completely agree. This wording is one I've always disagreed
with. Steve & I where always opposites regarding the use of more than
one `SeekHead`. As I've stated above I strongly prefer to allow two
`SeekHeads` with almost arbitrary placement (the first one must be
located before the first cluster and it must reference the second one)
and, more important, arbitrary content.

In writing mkvpropedit and the GUI's header editor it became painfully
obvious that editing existing files is simply not possible without
allowing a second `SeekHead` and using it for all types of 1
elements. If we disallow it then that would pretty much end all uses of
in-place editing of existing files without remuxing, something the users
would definitely not appreciate. Files that strictly follow the
guidelines are of course still editable, but my past experience is that
a very big percentage do not follow those guidelines and would not allow
editing (e.g. because there's no space after the first `SeekHead`).

> SeekHead. Any recommendations?

If we disregard the clusters: maybe 100 bytes or something like that?
One `SeekHead` entry is ~18 bytes in size, and leaving 100 bytes would
be plenty (adding attachments, chapters, tags are probably the most
interesting and most common use cases; the extra bytes would be a
reserve for future additions).

> The Tags ordering section suggests that if a Tags Element is at the
> beginning of the file and needs to be edited/expanded, then the Tags
> Element can be Voided, and a new one written at the end. But the Tags
> Element is allowed to occur multiple times. If someone is just added a
> new tag, could the new Tags Element just be written at the end of the
> Segment and the first Tags element left as is?

No. You'll have to relocate the whole element and add the new element to
the freshly moved `Tags` element.

Got to stop here as I have to go.

Kind regards,
mosu

---

From: Dave Rice <[email-masked]>
Date: Tue, 24 May 2016 10:01:56 -0400

Hi,

> On May 24, 2016, at 3:18 AM, Moritz Bunkus <[email-masked]> wrote:
> 
> Hey,
> 

Sorry to not clarify this well. The quote "The Matroska specification recommends that `CRC-32` Elements SHOULD
 NOT be used as an immediate Child Element of the `Segment` Element” is a proposal of mine. The current Matroska specification seems to permit a CRC-32 Element as an immediate Child Element of Segment.

>  lot of time and resources.

Agreed.

>  the whole element to be present in memory at the moment…

Agreed, but what if a non-Master-element was defined at Level 1 as an immediate child of Segment. Using a CRC-32 as a child of Segment would be the only way to represent the fixity of a non-Master-element at Level 1.

> in practice, and in practice you don't need `Clusters` to be referenced

Right, bad presumption of mine that SeekHead(s) should document all Top Level Elements. The current SeekHead definition does not mandate that all Top-Level Elements are referenced, but says "Contains the position of other Top-Level Elements." Steve confirmed that it is not a mandate to document all Top Level Elements here: https://mailarchive.ietf.org/arch/msg/cellar/UZMYejpNV7roYBsrXDzQKDfJSd0. I'll remove the mandate, rebase, and resubmit.

> not matter which `SeekHead` references which element – the player should

This is a mandate from the original documentation at https://matroska.org/technical/order/index.html: "The second Meta Seek is placed at the end and contains a lengthy list of all Clusters (and not the other level 1 elements)." Is the parenthetical part at the end indeed a mandate about the second SeekHead?

> applications (CRC-32: structure verification & editing; Voids: editing).

OK, without a mandate to reference all Top-Level Elements this question is less significant, but I could adjust this to say that the SeekHead should only reference Level 1 Elements, so that Void Elements may be listed in SeekHead.

> and, more important, arbitrary content.

I agree that two SeekHeads is sensible. Once the Matroska specdata.xml is updated as an EBML Schema we can use maxOccurs="2" for SeekHead as it seems that no one wants a third SeekHead. Going back to a quote from the original specification: "The second Meta Seek is placed at the end and contains a lengthy list of all Clusters (and not the other level 1 elements)." Are we agreed to remove this mandate that the second SeekHead not contain any non-Cluster Elements?

> editing (e.g. because there's no space after the first `SeekHead`).

It seems though that there are two bad options permitted when editing a file with one SeekHead that do not use a second SeekHead.

1. Void the SeekHead and add a new SeekHead at the end. This doesn't follow the recommendation of the Matroska specification but does not violate any mandate. Putting SeekHead before Clusters is a SHOULD and not a MUST.

2. Just Void the SeekHead and have no SeekHead at all. It presence is not a mandate.

> reserve for future additions).

Seems sensible, I'll add it as a suggestion.

> the freshly moved `Tags` element.

The "Tags" element is set to multiple. If not this case, when is it recommended to use more than one "Tags" Element?

> Got to stop here as I have to go.

[...]

Same here. Bye,
Dave Rice

---

From: Dave Rice <[email-masked]>
Date: Thu, 26 May 2016 07:45:33 -0400

> On May 24, 2016, at 10:01 AM, Dave Rice <[email-masked]> wrote:
> 
> Hi,
> 

Answering myself here, but perhaps Tags has multiple=“1” to allow it to be repeated in entirety at differing points in the Segment, such as:
<Segment>
	<Tags/>
	<Cluster/>
	<Tags/>
</Segment>

where the two <Tags> elements MUST be identical in storage and semantics. If this is so, then Tags should be defined as maxOccurs=“identical” in the EBML Schema.

Steve, Moritz, was this is the intent of repeating Tags?

> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

---

From: Moritz Bunkus <[email-masked]>
Date: Thu, 26 May 2016 13:57:42 +0200

Hey,

> where the two <Tags> elements MUST be identical in storage and
> semantics. If this is so, then Tags should be defined as
> maxOccurs=“identical” in the EBML Schema.
>

I honestly don't know/don't remember. Personally I'd prefer Tags,
Chapters, Attachments to be optional and unique (minOccurs="0"
maxOccurs="1") in order to avoid any ambiguity and to simplify software
dealing with those elements.

The intention with allowing "Tracks" multiple times was to improve
resilience by storing multiple identical copies
(maxOccurs="identical"). However, this does complicate things for
editing software. For example, neither mkvpropedit not MKVToolNix GUI's
header editor deal with such files properly and only change the first
"Tracks" element they find.

Kind regards,
mosu

---

From: Michael Bradshaw <[email-masked]>
Date: Thu, 26 May 2016 10:08:27 -0700

On Mon, May 23, 2016 at 8:07 PM, Dave Rice <[email-masked]> wrote:
>
> I started a rewrite of the Matroska Ordering Guideilnes in order to
> correct and clarify the recommendations and mandates of the section. I’ll
> include the updated text below and it is also reviewable as a pull request
> at https://github.com/Matroska-Org/matroska-specification/pull/16.
> Because this is a rewrite, it is difficult to diff, but please review what
> parts are deleted. This link is probably the most readable diff:
> https://github.com/Matroska-Org/matroska-specification/pull/16/commits/9fd95b3a0ad75ee49ac56b9f09efbebb7c08f1e3.
> Overall I’ve intended to keep the same meaning but form it more clearly,
> but this needs a review.
>

Overall I think it's an improvement. However, I still think calling them
"guidelines" but then using language like MUST is kind of confusing. If the
MUST mandates are truly requirements, then I suggest moving them into a
separate document that has an appropriate title.

Also, the structure of the spec(s) is kind of confusing because there are
multiple documents and it's not immediately clear what's intended to be
informative and what's intended to be authoritative. I think it would be
nice if all authoritative documents were compiled into a single document
(just with multiple sections/annexes), however if there are going to be
multiple RFCs then a single document makes less sense and I would suggest
each document clearly reference its dependencies (with language that makes
it clear what's a requirement and what's a guideline/purely informative).

---

From: Dave Rice <[email-masked]>
Date: Sat, 28 May 2016 11:13:03 -0400

> On May 26, 2016, at 1:08 PM, Michael Bradshaw <[email-masked]> wrote:
> 
> On Mon, May 23, 2016 at 8:07 PM, Dave Rice <[email-masked] <mailto:[email-masked]>> wrote:
> I started a rewrite of the Matroska Ordering Guideilnes in order to correct and clarify the recommendations and mandates of the section. I’ll include the updated text below and it is also reviewable as a pull request at https://github.com/Matroska-Org/matroska-specification/pull/16 <https://github.com/Matroska-Org/matroska-specification/pull/16>. Because this is a rewrite, it is difficult to diff, but please review what parts are deleted. This link is probably the most readable diff: https://github.com/Matroska-Org/matroska-specification/pull/16/commits/9fd95b3a0ad75ee49ac56b9f09efbebb7c08f1e3 <https://github.com/Matroska-Org/matroska-specification/pull/16/commits/9fd95b3a0ad75ee49ac56b9f09efbebb7c08f1e3>. Overall I’ve intended to keep the same meaning but form it more clearly, but this needs a review.
> 
> Overall I think it's an improvement. However, I still think calling them "guidelines" but then using language like MUST is kind of confusing. If the MUST mandates are truly requirements, then I suggest moving them into a separate document that has an appropriate title.

I could renaming it to "Ordering Requirements", though I think including both mandates and recommendations on ordering in the same section is okay, or possibly having one subsection on mandates and one subsequent subsection on recommendations.

> Also, the structure of the spec(s) is kind of confusing because there are multiple documents and it's not immediately clear what's intended to be informative and what's intended to be authoritative. I think it would be nice if all authoritative documents were compiled into a single document (just with multiple sections/annexes), however if there are going to be multiple RFCs then a single document makes less sense and I would suggest each document clearly reference its dependencies (with language that makes it clear what's a requirement and what's a guideline/purely informative).

We could have a makefile to concatenates markdown to make a single file. With this approach the individual pages could be processed separately if we’d like single-pages presentations as the current html is on matroska.org. The FFV1 spec uses a makefile [1] with markdown as well but then a makefile to create specific outputs.

At any rate, Ashley has been working on the markdown to rfc process and the results of that may impact the strategy for makefiles or many-docs vs single-doc.

Best Regards,
Dave Rice

[1] https://github.com/FFmpeg/FFV1/blob/master/Makefile