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