The only use is to be able to build the library to parse only Matroska version 1 elements. This has no use for pretty much anyone, and it's a pain to generate the code correctly.

In libmatroska2 all elements are supported in each build but marked for which version of Matroska/WebM/DivX they are allowed.

The selection of what subset you want should be done at runtime, not compilation time. Compiling with just just v1 elements won't make the code much smaller.

It shouldn't break ABI or API as it only adds classes for those (rare) people who only wanted v1 classes.

This thread is to discuss issues porting mkclean from libebml2/libmatroska2 (Core-C versions) to libebml/libmatroska 2.0.

The Core-C version was originally a port of the C++ code with some extra work on strengthening the coherence of data for mkvalidator and mkclean. So the internal design and philosphy is very similar. However there are a few extra things that are tricky to do with our C++ versions, at least in there current form.

Block timestamps

A Block timestamp depends on the Cluster timestamp, the Segment timestamp scale (and the track timestamp scale). So when you read or write the values you need to have all elements around. In libmatroska2 this is handled internally. When a Block is created it can be attached the Segment Info and Track Entry it belongs to. It's also attached its parent element (which itself has a parent element, etc).

Element reuse for writing

A Block read by mkclean is also used to write on the output. It has a different Segment Info/Track Entry for reading and writing in case they are modified (different timestamp scale for example).

Getter/Setter of keyframe flags

The SimpleBlock vs Block is partly hidden from the user. It's possible to read/write the keyframe info on either of them. While it's straightforward for a SimpleBlock, for a Block that means manipulating it parent BlockGroup (for example adding a dummy ReferenceBlock).

Frame duration

Each frame in a Block has a possibly known duration. This allows splitting blocks and not losing the duration when its known. In some cases it involves parsing the frame headers of some known codecs.

Cues linked to the Segment/Block

This is to get the position in the file just by using the Cues elements.

Some of these could be done by adding a weak reference to the parent in each element (except for the EbmlHead and Segment elements which have no parent).

Some others could be done by using a "shadow" version of some elements, Block in particular, so that when they are read a shadow version with more extra data can be created and the extra data set. Or we could do like libmatroska2 works: for example the Block objects have a few (hardcoded) extra fields that can be read/write.

The "shadow" versions might be done externally to libmatroska, but for that would should be able to add hooks when an EbmlElement is created to we can create a different/extended one. This is currently not possible with the hardcoded tables of elements and Create callbacks. Also it means a lot of casting between the base and the extended versions of an element.

Adding this hook to libebml could certainly be useful. However that means all the extra work to add stronger ties between elements would only be found in mkclean and not available to all libmatroska users. As we're doing the 2.0 versions this could be a rare opportunity to add this possibility, which should probably be optional, not to break existing code.

Currently, we are unable to build libmatroska and libebml in the same cmake "superbuild". In https://github.com/schultetwin1/libmatroska/blob/2cf0198cf3df9ced38c27fac9d45bea4fe8fd74f/CMakeLists.txt#L8-L9 CMAKE_MODULE_PATH is set to a non-existent path and then requires Ebml to be found via find_package. This means Ebml must be installed on your machine.

In our use case we have directories laid out in the following way:
/src
/extern
CMakeLists.txt
/ebml
CMakeLists.txt
... (The rest of the ebml code)
/matroska
CMakeLists.txt
... (The rest of the matroska code)

Since we are pulling in ebml by source and building it, we are able to build matroska without find_package working. However, we are unable to do so because find_package will currently always fail in this situation.

My solution is to not override CMAKE_MODULE_PATH. So that in our super build we can define an empty FindEbml.config file and be on our way.

With the API rework/cleanup for 2.0, it has become more apparent that a lof of the classes we define in KaxSemantic are just the base integer/string class with a semantic context attached.

Rather than creating these classes, we could just use the base types instead, just exporting the semantic of the element to identify would is what. Only a few classes (not found in KaxSemantic) would actually need to have proper C++ classes because they have extra methods.

These semantic are currently constexpr in KaxSemantics.cpp. We may be able to put these constexpr in KaxSemantics.h, eliminating the need to even export them from the DLL.

While this is true for libmatroska, this can also be done with all the elements in the EBML header in libebml.

There are no simple examples available.

One such simple example could be: creating a very basic H264 video file, in which you show how to add I frames and P or B frames.

I am trying to write an mkv file that I don't know the size of up front, so I am trying to stream video to an mkv file actually. I tried, but after 3 hours, I gave up, and used the older libmkv instead, which worked in 30 minutes. Just want to let you know that no examples hurts adoption of your library...

I don't want to repeat myself; please read the corresponding issue in libEBML.

For libMatroska it sems that release 1.7.0 is fine ABI-wise if built against the ABI-fixed libEBML branch v1.4.4-fix-abi-breakage. Here's the report from abidiff:

[0 mosu@sweet-chili ~/tmp/ebml-abi/m163] abidiff libmatroska.so.7.0.0 ~/opt/ebmlmatroska/lib/libmatroska.so.7.0.0
Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
Function symbols changes summary: 0 Removed, 31 Added function symbols not referenced by debug info
Variable symbols changes summary: 0 Removed, 24 Added variable symbols not referenced by debug info

31 Added function symbols not referenced by debug info:

  [A] _ZN11libmatroska11KaxEmphasisC1Ev
  [A] _ZN11libmatroska11KaxEmphasisC2Ev, aliases _ZN11libmatroska11KaxEmphasisC1Ev
  [A] _ZN11libmatroska16KaxEditionStringC1Ev, aliases _ZN11libmatroska16KaxEditionStringC2Ev
  [A] _ZN11libmatroska16KaxEditionStringC2Ev
  [A] _ZN11libmatroska16KaxTrickTrackUID10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska17KaxCodecDecodeAll10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska17KaxContentSigAlgo10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska17KaxEditionDisplayC1Ev, aliases _ZN11libmatroska17KaxEditionDisplayC2Ev
  [A] _ZN11libmatroska17KaxEditionDisplayC2Ev
  [A] _ZN11libmatroska17KaxReferenceFrame10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska17KaxTrickTrackFlag10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska18KaxChapterSkipTypeC1Ev, aliases _ZN11libmatroska18KaxChapterSkipTypeC2Ev
  [A] _ZN11libmatroska18KaxChapterSkipTypeC2Ev
  [A] _ZN11libmatroska18KaxContentSigKeyID10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska18KaxReferenceOffset10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska18KaxTagDefaultBogus10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska18KaxTagDefaultBogusC1Ev, aliases _ZN11libmatroska18KaxTagDefaultBogusC2Ev
  [A] _ZN11libmatroska18KaxTagDefaultBogusC2Ev
  [A] _ZN11libmatroska19KaxContentSignature10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska19KaxVideoAspectRatio10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska20KaxReferenceTimeCode10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska21KaxContentSigHashAlgo10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska21KaxTrackTimecodeScale10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska22KaxClusterSilentTracks10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska22KaxEditionLanguageIETFC1Ev, aliases _ZN11libmatroska22KaxEditionLanguageIETFC2Ev
  [A] _ZN11libmatroska22KaxEditionLanguageIETFC2Ev
  [A] _ZN11libmatroska22KaxTrickMasterTrackUID10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska23KaxTrickTrackSegmentUID10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska27KaxClusterSilentTrackNumber10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska29KaxTrickMasterTrackSegmentUID10RenderDataERN7libebml10IOCallbackEbb
  [A] _ZN11libmatroska9KaxSlices10RenderDataERN7libebml10IOCallbackEbb

24 Added variable symbols not referenced by debug info:

  [A] _ZN11libmatroska11KaxEmphasis10ClassInfosE
  [A] _ZN11libmatroska16KaxEditionString10ClassInfosE
  [A] _ZN11libmatroska17KaxEditionDisplay10ClassInfosE
  [A] _ZN11libmatroska18KaxChapterSkipType10ClassInfosE
  [A] _ZN11libmatroska18KaxTagDefaultBogus10ClassInfosE
  [A] _ZN11libmatroska22KaxEditionLanguageIETF10ClassInfosE
  [A] _ZTIN11libmatroska11KaxEmphasisE
  [A] _ZTIN11libmatroska16KaxEditionStringE
  [A] _ZTIN11libmatroska17KaxEditionDisplayE
  [A] _ZTIN11libmatroska18KaxChapterSkipTypeE
  [A] _ZTIN11libmatroska18KaxTagDefaultBogusE
  [A] _ZTIN11libmatroska22KaxEditionLanguageIETFE
  [A] _ZTSN11libmatroska11KaxEmphasisE
  [A] _ZTSN11libmatroska16KaxEditionStringE
  [A] _ZTSN11libmatroska17KaxEditionDisplayE
  [A] _ZTSN11libmatroska18KaxChapterSkipTypeE
  [A] _ZTSN11libmatroska18KaxTagDefaultBogusE
  [A] _ZTSN11libmatroska22KaxEditionLanguageIETFE
  [A] _ZTVN11libmatroska11KaxEmphasisE
  [A] _ZTVN11libmatroska16KaxEditionStringE
  [A] _ZTVN11libmatroska17KaxEditionDisplayE
  [A] _ZTVN11libmatroska18KaxChapterSkipTypeE
  [A] _ZTVN11libmatroska18KaxTagDefaultBogusE
  [A] _ZTVN11libmatroska22KaxEditionLanguageIETFE

As far as I can see all of those are additions that don't mess up ABI compatibility.

I'll test against a packaged MKVToolNix soon & will report whether or not it works.

That being said, if a distro has already packaged the bad libEBML v1.4.3 and built libMatroska 1.7.0 on top of libEBML v1.4.3, the resulting libMatroska 1.7.0 is likely NOT ABI compatible due to initialization changes in the Unix epoch thingy.

Therefore I suggest we do release libMatroska 1.7.1, even if the only changes in it are updates to the NEWS.md file & the version numbers — solely so that distributions have a clear incentive to update both libraries in tandem.

As I wrote, I'll test MKVToolNix next.

Hi,

I have been compiling the source code in VC++ 2008.
In libmatroska.h, most of the codes are showing grayed. I think it's just because of below line:

ifdef __cplusplus

extern "C" {

endif

ifdef OLD

As I am using C++, the macro __cplusplus is applicable here.

Please guide me how to expose functions or is there anything I am doing wrong.

I am somehow a new C++ developer, I am a C#, VB.NET working guy.

Thanks.

After building libebml and libmatroska on Windows using Visual Studio 2015, building an application, in this case an unit test, fails with unresolved dependencies like these:

... : error LNK2001: unresolved external symbol "public: static class libebml::EbmlCallbacks const libmatroska::KaxSeekHead::ClassInfos" (?ClassInfos@KaxSeekHead@libmatroska@@2VEbmlCallbacks@libebml@@B)
... : error LNK2001: unresolved external symbol "public: static class libebml::EbmlCallbacks const libmatroska::KaxInfo::ClassInfos" (?ClassInfos@KaxInfo@libmatroska@@2VEbmlCallbacks@libebml@@B)
... <several more of these errors> 
... : error LNK2001: unresolved external symbol "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const libmatroska::KaxCodeVersion" (?KaxCodeVersion@libmatroska@@3V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@B)

After investigating these problem I figured out two problems:

1.) The MATROSKA_DLL_API is set to nothing, when the libmatroska header file are included in my project.
2.) The KaxCodeVersion variable is not exported

Right now I am preparing a pull request for solving these link problem.

Per deb546d C++11 is required but README.md doesn't mention it; it only says:

libmatroska [...] requires a C++ compiler

I think the so-version should be incremented, because a so version of 6 means that libmatroska.so.6 is abi compatible to all libmatroska.so.6.* but with the last change this is not true anymore.

Problem I had:
I have built mkvtoolnix 9.3.1 which requires 1.4.5, but then after installing the mkvtoolnix package mkvtoolnix requires only libmatroska.so.6 but the system-one (1.4.4) does not provide the symbol:

_ZN11libmatroska14KaxVideoColour10ClassInfosE

And if I understand this gnu guideline correctly:
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
After adding this new interface the "current" should be incremented.

I'm having trouble setting up libmatroska without the sudo.
The commands are:
-To configure libebml

cmake -DCMAKE_INSTALL_PREFIX=$HOME/libebml ..
make
make install

and ok
-To configure libmatroska
cmake -DCMAKE_INSTALL_PREFIX=/$HOME/libmatroska DEbml_DIR=$HOME/libebml/include/ebml/
and
cmake -DCMAKE_INSTALL_PREFIX=/$HOME/libmatroska DEbml_DIR=$HOME/libebml/
Return:

CMake Error at CMakeLists.txt:8 (find_package):
  By not providing "FindEBML.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "EBML", but
  CMake did not find one.

  Could not find a package configuration file provided by "EBML" (requested
  version 1.3.9) with any of the following names:

    EBMLConfig.cmake
    ebml-config.cmake

  Add the installation prefix of "EBML" to CMAKE_PREFIX_PATH or set
  "EBML_DIR" to a directory containing one of the above files.  If "EBML"
  provides a separate development package or SDK, be sure it has been
  installed.


-- Configuring incomplete, errors occurred!

How can I fix this?

I am writting here because i just cannot find the solution of how to built libmatroska dll's library with visual studio 2005 and google didn't help this time. If this is not the place to ask forgive me and please indicate me where to. I downloaded the code form the source at Git's repo. I First thing was to open the project in make/vc7/ folder then delete from project file included but not existing as KaxChapters.cpp, KaxClusterData.cpp etc... The projetc include projects: libebml, libebmldll, libmatroska, libmatroskadll and others test related. The first 3 compile just fine after remove the non-existing files and adding the dependences at properties->Reference o the selected project. The code of libmatroskadll error at linking process. Any help is appreciated. I obtained about 5000 error similar to the nexts:

    Linking...

1> Creating library Debug/libmatroska.lib and object Debug/libmatroska.exp
1>KaxInfoData.obj : error LNK2001: unresolved external symbol "public: static class libebml::EbmlCallbacks const libmatroska::KaxSeekID::ClassInfos" (?ClassInfos@KaxSeekID@libmatroska@@2VEbmlCallbacks@libebml@@b)
1>KaxSeekHead.obj : error LNK2001: unresolved external symbol "public: static class libebml::EbmlCallbacks const libmatroska::KaxSeekID::ClassInfos" (?ClassInfos@KaxSeekID@libmatroska@@2VEbmlCallbacks@libebml@@b)
1>KaxSegment.obj : error LNK2001: unresolved external symbol "public: static class libebml::EbmlCallbacks const libmatroska::KaxSeekID::ClassInfos" (?ClassInfos@KaxSeekID@libmatroska@@2VEbmlCallbacks@libebml@@b)

See https://github.com/Matroska-Org/libmatroska/blob/release-1.6.1/CMakeLists.txt#L3.
This reflects upon libmatroska.pc.

i can not find a file where there is the association codec matroska --> codec mse
https://www.matroska.org/technical/specs/codecid/index.html
Examples of valid MIME-types with a codecs parameter.

audio/webm;codecs="vorbis"
video/webm;codecs="vorbis"
video/webm;codecs="vp8"
video/webm;codecs="vp8,vorbis"
video/webm;codecs="vp9,opus"

The EBML lacing is using a VINT unsigned integer with values shifted to positive. The current code is using libebml code to do that, even though this is not an EBML thing. That code should be moved here (won't break API).

Moreover, that libebml code is not allowing +64 to be encoded on 1 octet even thought there's room for it. This should be fixed as well. Both libmatroska and libavformat can read it properly on 1 octet, see discussion here: ietf-wg-cellar/matroska-specification#733 (comment)

https://github.com/Matroska-Org/libebml/blob/a81936929f9c2c21e0ed0e11476df42a01111eb8/src/EbmlElement.cpp#L93
https://github.com/Matroska-Org/libebml/blob/a81936929f9c2c21e0ed0e11476df42a01111eb8/src/EbmlElement.cpp#L130
https://github.com/Matroska-Org/libebml/blob/a81936929f9c2c21e0ed0e11476df42a01111eb8/src/EbmlElement.cpp#L189

I'm not a C++ developer but i'm trying to compile this project. I'm getting the error:

no such file or directory: ./configure

when running ./configure inside a directory that I downloaded from the releases page. Is there something wrong with what I'm doing?

Build of some tests fails (ran on Fedora 39 and Ubuntu 22.04).

mux/test6.cpp aborts when ran. Tested with 1.7.1 and latest 1.x.

GDB output:

Creating "muxed.mkv"
test6: /builddir/build/BUILD/libmatroska-1.7.1/src/KaxSemantic.cpp:931: virtual filepos_t libmatroska::KaxContentSigAlgo::RenderData(libebml::IOCallback&, bool, bool): Assertion `false' failed.

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
44            return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;

Trace:

#5  0x00007ffff7973c57 in __assert_fail (assertion=0x7ffff7f5f84d "false",
    file=0x7ffff7f62698 "/builddir/build/BUILD/libmatroska-1.7.1/src/KaxSemantic.cpp", line=931,
    function=0x7ffff7f633a0 "virtual filepos_t libmatroska::KaxContentSigAlgo::RenderData(libebml::IOCallback&, bool, bool)") at assert.c:101
#6  0x00007ffff7f542c7 in libmatroska::KaxContentSigAlgo::RenderData (this=<optimized out>)
    at /usr/src/debug/libmatroska-1.7.1-4.fc39.x86_64/src/KaxSemantic.cpp:931
#7  0x00007ffff7ec9086 in libebml::EbmlElement::Render (this=0x421e20, output=..., bWithDefault=false, bKeepPosition=false,
    bForceRender=false) at /home/work/.hunter/_Base/cb0ea1f/187c4c7/461adde/Build/EBML/Source/src/EbmlElement.cpp:597
#8  0x00007ffff7ecadae in libebml::EbmlMaster::RenderData (this=0x421c40, output=..., bForceRender=false, bWithDefault=false)
    at /home/work/.hunter/_Base/cb0ea1f/187c4c7/461adde/Build/EBML/Source/src/EbmlMaster.cpp:100
#9  0x00007ffff7ec9086 in libebml::EbmlElement::Render (this=0x421c40, output=..., bWithDefault=false, bKeepPosition=false,
    bForceRender=false) at /home/work/.hunter/_Base/cb0ea1f/187c4c7/461adde/Build/EBML/Source/src/EbmlElement.cpp:597
#10 0x00007ffff7ecadae in libebml::EbmlMaster::RenderData (this=0x4218e0, output=..., bForceRender=false, bWithDefault=false)
    at /home/work/.hunter/_Base/cb0ea1f/187c4c7/461adde/Build/EBML/Source/src/EbmlMaster.cpp:100
#11 0x00007ffff7ec9086 in libebml::EbmlElement::Render (this=0x4218e0, output=..., bWithDefault=false, bKeepPosition=false,
    bForceRender=false) at /home/work/.hunter/_Base/cb0ea1f/187c4c7/461adde/Build/EBML/Source/src/EbmlElement.cpp:597
#12 0x00007ffff7ecadae in libebml::EbmlMaster::RenderData (this=0x421830, output=..., bForceRender=false, bWithDefault=false)
    at /home/work/.hunter/_Base/cb0ea1f/187c4c7/461adde/Build/EBML/Source/src/EbmlMaster.cpp:100
#13 0x00007ffff7ec9086 in libebml::EbmlElement::Render (this=0x421830, output=..., bWithDefault=false, bKeepPosition=false,
    bForceRender=false) at /home/work/.hunter/_Base/cb0ea1f/187c4c7/461adde/Build/EBML/Source/src/EbmlElement.cpp:597
#14 0x00007ffff7ecadae in libebml::EbmlMaster::RenderData (this=0x421190, output=..., bForceRender=false, bWithDefault=false)
    at /home/work/.hunter/_Base/cb0ea1f/187c4c7/461adde/Build/EBML/Source/src/EbmlMaster.cpp:100
#15 0x00007ffff7ec9086 in libebml::EbmlElement::Render (this=0x421190, output=..., bWithDefault=false, bKeepPosition=false,
    bForceRender=false) at /home/work/.hunter/_Base/cb0ea1f/187c4c7/461adde/Build/EBML/Source/src/EbmlElement.cpp:597
#16 0x00007ffff7ecadae in libebml::EbmlMaster::RenderData (this=0x420bd0, output=..., bForceRender=false, bWithDefault=false)
    at /home/work/.hunter/_Base/cb0ea1f/187c4c7/461adde/Build/EBML/Source/src/EbmlMaster.cpp:100
#17 0x00007ffff7ec9086 in libebml::EbmlElement::Render (this=0x420bd0, output=..., bWithDefault=false, bKeepPosition=false,
    bForceRender=false) at /home/work/.hunter/_Base/cb0ea1f/187c4c7/461adde/Build/EBML/Source/src/EbmlElement.cpp:597
#18 0x0000000000404d80 in main (argc=1, argv=0x7fffffffd868) at /home/work/workspaces/lib/libmatroska/test/mux/test6.cpp:203

As per title: CMakeLists.txt has

  set(prefix ${CMAKE_INSTALL_PREFIX})
  set(exec_prefix "\$\{prefix\}")
  set(libdir "\$\{prefix\}/${CMAKE_INSTALL_LIBDIR}")
  set(includedir "\$\{prefix\}/${CMAKE_INSTALL_INCLUDEDIR}")

and so can’t handle absolute paths in CMAKE_INSTALL_{INCLUDE,LIB}DIR. This leads to a broken .pc file on NixOS in particular.

Identical to Matroska-Org/libebml#97. Similar to open-source-parsers/jsoncpp#1199. See “Concatenating paths when building pkg-config files” for a discussion of the problem in a somewhat different context and a suggested fix (I don’t know CMake myself, sorry).

Looking at #148 which embeds the information about the minimum & maximum version number an element is valid for in libMatroska, I thought about also having the information available which values are valid for the various enums we have in the specs. At the moment we only have C-style enum for them, which means we can use them in the code via their names, but there's no way to have the program query the library if a given value is valid or not.

For example, it would be nice to be able to query libMatroska & ask if the value 1 is valid for the "color primaries" element (it is) or if 14 is (it isn't).

On top of that it would be nice if the library simply provided a list of valid value/description pairs that an application can use for selection or to translate what a given value refers to (think mkvinfo outputting the name of the "color primaries" along with the numeric value).

I'm thinking about two or three functions, the example being for an unsigned integer-based enum:

static bool IsValueInSpecs(uint64_t value);
static std::string GetDescriptionForValueFromSpecs(uint64_t value);
static std::vector<std::pair<uint64_t, std::string>> GetValuesDescriptionsFromSpecs();

I'm trying to avoid the word "valid" here as these functions are all static; they only provide information straight from the specs. Not really happy with the names, though…

The Ebml_DIR option mention in the README.md doesn't exist and is ignored. I'm not sure what it the correct way to signal this (some combination of CMAKE_MODULE_PATH probably).

http://x265.org/

https://bitbucket.org/multicoreware/x265/wiki/Home

@robUx4 I'd like to make new releases of libEBML & libMatroska soon in order to be able to start supporting the new elements in MKVToolNix. Do you plan to add any more things soon?

The only thing left for me to merge is #66 . I'm also aware of ietf-wg-cellar/matroska-specification#670 which we should probably include in the release. Anything else?

The verification checks don't work with this simple code:

  KaxClusterPosition t;
  const auto & spec = t.ElementSpec();
  const auto profiles = reinterpret_cast<const MatroskaProfile *>(&spec.GetVersions());
  assert(profiles->IsValidInVersion(1));

The pointer from GetVersions is bogus (also fails when not using pointers). It might be an issue with the storage in EbmlCallbacks which is not big enough. We need unit tests in libebml and libmatroska to make sure it's OK and remains that way.

I'm a French Canadian who've been working with MKV files since they're out and I can tell that the French language flag needs to be updated to take into consideration the Canadian French language. Most of the movies since the 90's are dubbed in French in the province of Quebec. It's really hard to distinguish between the 3 categories of french language. From my knowledge there are 3 main categories.

1. International French also known as VFI
2. French also known as Truefrench or VFF
3. French Canadian also known as VFQ

When remuxing a bluray that has both french language there wont have any distinction between them unless you write a custom audio track name. This has been an issue for years on streaming services like Amazon and also on P2P sharing communities. It would be great to standardize this so we could use the custom track name for describing the audio format which is how I understand MKV was meant to do it originally.

Something isn't quite right when the EBML and Matroska libraries are built as shared objects. Here is how to replicate:

1. Configure, build, and install EBML and Matroska as follows:

cmake -DCMAKE_INSTALL_PREFIX:PATH=/tmp/matroska -DCMAKE_BUILD_TYPE=RELWITHDEBINFO -DBUILD_SHARED_LIBS=YES ..

2. Try to build the simple test-case project I provide here: https://github.com/Rupan/mktest

The link stage fails:

michael@winterfell:~/git/mktest/build$ make
Scanning dependencies of target main
[ 50%] Building CXX object CMakeFiles/main.dir/main.cpp.o
[100%] Linking CXX executable main
/usr/bin/ld: CMakeFiles/main.dir/main.cpp.o: in function `main':
main.cpp:(.text+0x32): undefined reference to `libebml::EbmlCodeVersion[abi:cxx11]'
/usr/bin/ld: main.cpp:(.text+0x6d): undefined reference to `libmatroska::KaxCodeVersion[abi:cxx11]'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/main.dir/build.make:86: main] Error 1
make[1]: *** [CMakeFiles/Makefile2:73: CMakeFiles/main.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
michael@winterfell:~/git/mktest/build$ 

For historical reasons there are several classes & functions that use the word timecode in their name, whereas what they're dealing with are actually timestamps, not timecodes. When working on the specs we decided to rename the elements in the specs but not in the libraries for compatibility purposes. As we're breaking the API & ABI left & right already, maybe now's the time to fix this inconsistency in the libraries, too?

The autotools infrastructure for libmatroska and libebml allowed for building both shared and static libraries.

The new CMake infrastructure appears to only be able to build shared OR static libraries depending on the setting of BUILD_SHARED_LIBS instead of enabling both.

The tags list includes IMDB and TMDB tags for movie ratings. I suggest adding one for Rotten Tomatoes, a site known for overall critical ratings ( the 'tomatometer').