[matroska-general] Re: H.264 updates

Pamel Paul at msn.com
Thu Mar 13 16:25:06 CET 2003


"Steve Lhomme" <steve.lhomme at free.fr> wrote
> The result of our brainstorming has come to a good result. We *do* can
store it
> nicely in matroska, provided we make these additions to the specs :
> - a BlockGroup can contain many Block as long as they all have the same
timecode
> - 3 bits in the Block head will be allocated to the Block priority (that
makes 8
> possible values, I hope it's enough for H.264).

You would need a minimum of 4 bits to cover the defined categories, and 8
bits to have what they have.
(See Table below.

I think that you should consider doing a variation on idea 2.  Keep the
Block structure the same.  But then add another element that included an
8bit category setting.  This would save a full byte/block in 99.99999999% of
cases until H.264 actually starts being used in a few years.  Store the
highest priority NALU in a regular block too, as you can't drop those
anyway.  And then store all other category blocks in (BlockNALU's?), setting
the category byte appropriately.

That way you would still save space, even when storing H.264, and the
streamer would automatically know that it CAN NOT drop a regular block, but
it could drop a (BlockNALU?) starting at the lowest priority.


Table 7-1   NAL Unit Type Codes
"Value of nal_unit_type"
"Content of NAL unit"
"Category"

0x0
Reserved for external use

0x1
Coded slice
4, 5, 6

0x2
Coded data partition A (DPA)
4

0x3
Coded data partition B (DPB)
5

0x4
Coded data partition C (DPC)
6

0x5
Coded slice of an IDR picture
4, 5

0x6
Supplemental Enhancement Information (SEI)
7

0x7
Sequence Parameter Set (SPS)
0

0x8
Picture Parameter Set (PPS)
1

0x9
Picture Delimiter (PD)
8

0xA
Filler Data (FD)
9

0xB   0x17
Reserved

0x18   0x1F
For external use


Pamel



http://www.matroska.org




More information about the Matroska-general mailing list