[Matroska-devel] Fwd: [Matroska-users] MKV EBML lacing questions.

Steve Lhomme slhomme at matroska.org
Sun Jan 9 16:38:59 CET 2011


---------- Forwarded message ----------
From: Steve Lhomme <slhomme at matroska.org>
Date: Sun, Jan 9, 2011 at 4:38 PM
Subject: Re: [Matroska-users] MKV EBML lacing questions.
To: "Questions, help, instructions, talk about Matroska"
<matroska-users at lists.matroska.org>


The "EBML" lacing is a little different than the EBML encoding of
integers in the rest of Matroska. This time it is signed.

Here is some simple code that does this little trick for you. It takes
the regular EBML value that is coded and then remove the offset
dependings on the size of the buffer (in your case 2).

filepos_t EBML_ReadCodedSizeSignedValue(const uint8_t *InBuffer,
size_t *BufferSize, filepos_t *SizeUnknown)
{
filepos_t Result = EBML_ReadCodedSizeValue(InBuffer, BufferSize, SizeUnknown);

if (*BufferSize != 0)
{
switch (*BufferSize)
{
case 1:
Result -= 63;
break;
case 2:
Result -= 8191;
break;
case 3:
Result -= 1048575L;
break;
case 4:
Result -= 134217727L;
break;
}
}

return Result;
}


On Wed, Jan 5, 2011 at 7:16 PM, Dan Wright <oodsphere at gmail.com> wrote:
> I'm working on an MKV writer and an MKV parser, and I'm trying to add lacing
> support.  I'm using the MKV specs at
> http://matroska.org/technical/specs/index.html.  As such, I've got a couple
> of questions about the EBML lacing method.  Having run fruitless searches on
> Google and on these mailing lists, here are my questions:
>
> 1.  It looks like EBML lacing use "one's complement" for its lacing sizes.
> Is this correct?  It seems a little non-standard, especially since, earlier
> in the spec, it is evident that the signed integer data element type uses
> the much more common "two's complement" (e.g. -2 = 0xFE).
>
> 2.  The example for EBML lacing uses an example where the first frame is 800
> bytes, the second 500, and the third 1000.  The spec example claims:
>
> "Lacing sizes: only the 2 first ones will be coded, 800 gives 0x320 + 0x4000
> = 0x4320, 500 is coded as -300 : - 0x12C + 0x1FFF + 0x4000 = 0x5ED3. The
> size of the last frame is deduced from the total size of the Block."
>
> Now, I'm fine with encoding 800 as 0x4320, but encoding -300 as 0x5ED3
> leaves me with a problem.  If I were decoding 0x5ED3, the first bit
> encountered after the EBML size-bits is a 0, leading me to interpret the
> value as positive, getting 7891 instead of -300.  Assuming a one's
> complement system, shouldn't this value actually be 0x7ED3 so that the most
> significant digit after the EBML size-bits is a 1?  Or am I missing
> something obvious?
>
> Thanks for any help!
>
>
>
> _______________________________________________
> Matroska-users mailing list
> Matroska-users at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-users
> Read Matroska-Users on GMane:
> http://dir.gmane.org/gmane.comp.multimedia.matroska.user
>
>



--
Steve Lhomme
Matroska association Charmain




-- 
Steve Lhomme
Matroska association Charmain



More information about the Matroska-devel mailing list