Users should be able to decode an EBML body into a map[string]interface{} just like when calling Unmarshal/Decode in encoding/json.

At the moment decoding uses a generated struct as schema definition. It would be beneficial to define schema separately and make decoding independent of the provided struct. This would allow for users to provide their own struct to decode only the fields they need or map[string]interface{} to decode everything (including Void and CRC32 elements).

Proposed definition:

type Definition struct {
	ID      []byte
	Type    string
	Name    string
	Default interface{}
	Parent  *Definition
}

The level number can be calculated from counting the parents or by adding an extra field.

Provide a way to extract the content of a track into a io.Writer.

https://www.matroska.org/technical/codec_specs.html

EBML allows elements to be defined recursively.

https://www.rfc-editor.org/rfc/rfc8794#section-11.1.6.11

To make this work the library has to handle elements with Unknown Data Size and multiple Documents (or continuous Header and Segment elements).

• Support for Unknown Data Size
• Support for reading more than one EBML Document

EBML Stream

An EBML Stream is a file that consists of one or more EBML Documents that are concatenated together. An occurrence of an EBML Header at the Root Level marks the beginning of an EBML Document.

Source: https://www.rfc-editor.org/rfc/rfc8794#name-ebml-stream

Matroska Livestreaming

Livestreaming

[...]

A live Matroska stream is different from a file because it usually has no known end (only ending when the client disconnects). For this, all bits of the “size” portion of the Segment Element MUST be set to 1. Another option is to concatenate Segment Elements with known sizes, one after the other. This solution allows a change of codec/resolution between each segment. For example, this allows for a switch between 4:3 and 16:9 in a television program.

[...]

Source: https://www.matroska.org/technical/streaming.html

Element ID

The theoretical maximum byte length of Element ID is infinite. Its length is defined by EBMLMaxIDLength. ebml.xml defines EBMLMaxIDLength as type="uinteger" range=">=4" default="4".

In reality it is not likely to have a EBMLMaxSizeLength greater than 4. The library could handle values up to 7 and if this value is greater than 7 the library could return an error saying the EBML document cannot be parsed by this lib.

In case EBMLMaxSizeLength has a value of 7, the maximal value it can contain is 2^56-2 which fits into uint64 and int64 as well.

Element Data Size

The theoretical maximum byte length of Element Data Size is infinite. Its length is defined by EBMLMaxSizeLength. ebml.xml defines EBMLMaxSizeLength as type="uinteger" range="not 0" default="8". The library uses big.Int to be compatible with this specification.

In reality it is not likely to have a EBMLMaxSizeLength greater than 8. In case this value is greater than 8 the library could return an error saying the EBML document cannot be parsed by this lib.

The value of EBMLMaxSizeLength has a direct connection with VINTMAX. VINTMAX limits the value of known Element Data Sizes.

In case EBMLMaxSizeLength has a value of 8, the value of VINTMAX is 2^56-2 which fits into uint64 and int64 as well.

In such cases when reading the whole content of an EBM document into memory there should be a way to scan through it.

Questions:

1. How to iterate?
2. How to skip child elements?
3. How to seek?

In the current design DecodeBody accepts ebml.EBML (EBML Header) as it's second parameter to make sure DecodeHeader is called first. Maybe it would be better to reconsider this decision and store the header info in the decoder struct.

Option 0

Based on encoding/xml

f, err := os.Open("/foo/bar")
// handle error
d := ebml.NewDecoder(f)
var h ebml.EBML
// decode header
for {
	el := d.Element()
	// handle element
}

Question 2 and 3 applies.

Option 1

Based on text/scanner.

f, err := os.Open("/foo/bar")
// handle error
d := ebml.NewDecoder(f)
var h ebml.EBML
// decode header
s := d.Scanner(h)
// decode header
for s.Next(&h) {
	el := s.Element()
	// handle element
}

Question 2 and 3 applies.

Option 2

Based on github.com/yuin/goldmark/ast

f, err := os.Open("/foo/bar")
// handle error
s := ebml.NewDecoder(f)
var h ebml.EBML
// decode header
ast.Walk(h, func(el ebml.Element) (ebml.WalkStatus, error) {
	// handle element
	// return ebml.WalkStop, nil
	// return ebml.WalkSkipChildren, nil
	return ebml.WalkContinue, nil
})

Question 3 applies.

Go 1.6 added embed which allows to embed a file into the binary of a package with a simple directive. This would simplify the definition of Doc Types. No more code generation would be needed.