How to write "0" value?

[cbagpipe]

When I'm trying to write cue point with following code

cuePoint.Write(VInt.FromEncoded(0xB3), absoluteTimestamp); /* CueTime */

and absoluteTimestamp is 0. I'm getting 0xB3 0x80 in raw bytes instead of expected 0xB3 0x81 0x00
Am I doing something wrong?

[OlegZee]

No, you are doing it right.
According to https://www.rfc-editor.org/rfc/rfc8794.html#name-vint-examples the value of 0 is encoded with 1 octet:
1xxx xxxx where xxxxxxx = 0 results in 0x80.

[andrekoehler]

@OlegZee
I also stumbled upon this issue. The matroska element "Tracks.TrackEntry.FlagLacing" has a defined default value of 1 (see https://matroska.org/technical/elements.html). I want it to have a value of 0. In my old MKV files created with an older (and modified by me) version of NEbml I can see it being correctly written as 9C 81 00. With the new version 0.10.1 of the NEbml NuGet package I get 9C 80 instead. https://www.rfc-editor.org/rfc/rfc8794.html#section-7.2 states "If the EBML Element is not defined to have a default value, then an Unsigned Integer Element with a zero-octet length represents an integer value of zero.". So in my opinion NEbml incorrectly assumes that the default value for all integers is always 0, but this is not true.

[OlegZee]

Well, section 6.1 (https://www.rfc-editor.org/rfc/rfc8794.html#section-6.1) is even more interesting.
If I understand it correctly long/ulong values should use length of 1 or more.
I could provide WriteDefault(VInt elementId) for legacy behavior (zero length), which could be used for strings as well.
Btw empty string will be encoded with 0 length as well.

Would it work?

[andrekoehler]

Well, section 6.1 (https://www.rfc-editor.org/rfc/rfc8794.html#section-6.1) is even more interesting.
If I understand it correctly long/ulong values should use length of 1 or more.

I don't read it like that. Length of 1 or more is only required for EBML element IDs.

an Element Data Size with all VINT_DATA bits set to zero is allowed for EBML Element Types that do not mandate a nonzero length

A Signed Integer Element MUST declare a length from zero to eight octets

An Unsigned Integer Element MUST declare a length from zero to eight octets.

Maybe you could just add an overload with nullable values to the EbmlWriter.Write method and add EbmlReader.ReadNullable* methods?
Examples:

// A value of null will be written with a VINT length of zero bytes, zero will be written with a length of one byte.
public int Write(VInt elementId, long? value)
public int Write(VInt elementId, ulong? value)

// A VINT length of zero will be returned as null
public long? ReadNullableInt()
public ulong? ReadNullableUInt()

This way during writing I could write an empty integer by providing a typed null (with the expression default(long?)) or write a one-byte value of zero using (long?)0.

I believe old code would not be affected because it would always call the Write-method-overload which does not use the System.Nullable type.

[OlegZee]

I suppose it's redundant.
Which one would be used if I write code like this Write(DurationElementId, null)?
Besides that we don't care about backword compabitility so both options look the same.

Regarding reading: looks fine to me.

[andrekoehler]

I suppose it's redundant.
Which one would be used if I write code like this Write(DurationElementId, null)?

Good point, I did not think about that. I just tested it with a test project and it seems like there is a priority between integer types when selecting between Nullable overloads. When having to chose between int?, uint?, long? and ulong? C# picks the overload with int? but as soon as an overload with string exists I get "error CS0121: The call is ambiguous". So my idea was not good I guess.

Next idea: Specify the default value in the write call. If the value equals the default value, the element is written with a length of zero:

public int Write(VInt elementId, long value, long defaultValue = 0)
public int Write(VInt elementId, ulong value, ulong defaultValue = 0)

[OlegZee]

Hm… The good point is that it’s backward compatible, i.e. 0 will be written as 80. Does it work well for your scenario: you will have to pass a different value in the last parameter?  Also we can made Read methods similarly, i.e. int ReadInt(int defaultValue = 0)

[andrekoehler]

Passing the default value to each Write and Read method would work for me, because my Matroska (de-/)serializer knows it for each element (I use a System.Attribute to store that information).