Data corruption when writing very simple files with libebml 1.4.5

[dgatwood]

I wrote some code to try to write h.265 and AAC data to a file using libmatroska, and I kept running into a problem where the tracks were getting corrupted on output. Basically, the video track's info was getting jammed into the node for the audio track, so it had multiple track numbers, followed by a bunch of garbage.

And right now, I'm not even writing any frames, so that garbage output is all from the corrupted track data.

I spent basically an entire day trying to figure out what was wrong with my code, and finally in desperation, I built libmatroska and libebml from top-of-tree on GitHub and the bug went away. The only changes I made were adjusting all the last parameters in Render and a couple of other methods from true to EbmlElement::WriteSkipDefault, plus renaming timecode -> timestamp in various places, so this bug likely isn't being caused by my code, but rather by a bug in libebml 1.4.5.

I realize 1.4.5 was over a year ago, so I'm not sure if 1.4.5 is still supported in any way, but the code basically came straight out of libmatroska/tree/master/test/mdx/test6.cpp with only minor changes:

• Deleted the encryption and compression bits
• Added KaxVideoFlagInterlaced
• Added KaxVideoFieldOrder
• Used real codec IDs for H.265 and AAC

The track data from a working libebml looks like this

Tracks: (master) [90 bytes]

• TrackEntry: (master) [40 bytes]
• • TrackNumber: 1
• • TrackUID: 4
• • TrackType: 2
• • CodecID: 'A_AAC/MPEG4/MAIN'
• • Audio: (master) [10 bytes]
• • • SamplingFrequency: 44100.000000
• • • BitDepth: 32
• TrackEntry: (master) [46 bytes]
• • TrackNumber: 2
• • TrackUID: 42
• • TrackType: 1
• • FlagLacing: 0
• • CodecID: 'V_MPEG4/ISO/AVC'
• • Video: (master) [14 bytes]
• • • FlagInterlaced: 2
• • • FieldOrder: 0
• • • PixelWidth: 3840
• • • PixelHeight: 2160

The bad data looks like this:

Tracks: (master) [216 bytes]

• TrackEntry: (master) [94 bytes]
• • TrackNumber: 1
• • TrackUID: 4
• • TrackType: 2
• • FlagEnabled: 1
• • FlagDefault: 1
• • FlagForced: 0
• • FlagLacing: 1
• • MinCache: 0
• • TrackTimestampScale: 32779727273984.000000
• • Language: 'eng'
• • CodecID: 'A_AAC/MPEG4/MAIN'
• • CodecDecodeAll: 86
• • CodecDecodeAll: 0
• • SeekPreRoll: 0
• • Audio: (master) [17 bytes]
• • • SamplingFrequency: 44100.000000
• • • Channels: 1
• • • DummyElement: [52F1] [1 bytes]
• • • BitDepth: 32
• • TrackNumber: 2
• DummyElement: [73C5] [1 bytes]
• DummyElement: [83] [1 bytes]
• DummyElement: [B9] [1 bytes]
• DummyElement: [88] [1 bytes]
• DummyElement: [55AA] [1 bytes]
• DummyElement: [9C] [1 bytes]
• DummyElement: [6DE7] [1 bytes]
• DummyElement: [23314F] [4 bytes]
• DummyElement: [22B59C] [3 bytes]
• DummyElement: [86] [15 bytes]
• DummyElement: [AA] [1 bytes]
• DummyElement: [AA] [1 bytes]
• DummyElement: [56BB] [1 bytes]
• DummyElement: [E0] [42 bytes]

I have no idea what's going on, but given that it doesn't happen in current sources, I'm assuming this is a bug. If libebml 1.x is still in any way supported, is there any chance that the bug fix that fixes this could be backported? I'm assuming there are reasons that 2.x isn't part of Homebrew yet, so...

Thanks.

[dgatwood]

The code I use to swap between APIs is

#if LIBEBML_VERSION < 0x020000
#define OLD_LIBEBML
#endif

#ifdef OLD_LIBEBML
#include <ebml/EbmlSubHead.h>
#endif

#ifdef OLD_LIBEBML
static bool kShouldWriteDefaultValues = true;
#define KaxTimestampScale KaxTimecodeScale
#define SetGlobalTimestampScale SetGlobalTimecodeScale
#define SetPreviousTimestamp SetPreviousTimecode
#else
static const EbmlElement::ShouldWrite kShouldWriteDefaultValues = EbmlElement::WriteSkipDefault;
#endif

so you can probably reverse that and get pretty close to running the mux test #6 against the old code and maybe see this behavior, assuming it isn't specific to one of those seemingly minor changes I made.

[robUx4]

Hi,

It would be helpful to have the actual bogus/working code to tell what could be done wrong. Guessing which lines of test6.cpp have been modified is not going to come close.
Since the last release of libmatroska it has seen a few changes https://github.com/Matroska-Org/libmatroska/commits/v1.x/test/mux/test6.cpp as well. Although the changes are block related, it should no affect the Tracks element.

As for the 2.x branches, they are still under development and should not be used for production (or packaging).