[matroska-general] Re: H.264 updates

Steve Lhomme steve.lhomme at free.fr
Thu Mar 13 16:54:22 CET 2003


En réponse à Pamel <Paul at msn.com>:

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

See my comment 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.

It's not as simple as this. If you add many Blocks to a BlockGroup you have no
way of knowing which priority is associated to which Block. So I don't think
it's such a good option.

As for CRC, the order might be important. But I don't like too much that the
order of elements become sensitive. That's why I have avoided making the CRC
code so far.

> 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
>
> ....
>
> 0xB   0x17
> Reserved
> 
> 0x18   0x1F
> For external use

OK, that makes 5 bits (0x00 to 0x1F). That leaves 1 free/unused/reserved in the
Block. And we handle all cases covered by H.264 (the most complex big codec of
the coming years) in a cleaner way, even the cases not covered by their specs.
http://www.matroska.org




More information about the Matroska-general mailing list