[matroska-general] Re: H.264 updates
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
> Block structure the same. But then add another element that included
> 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
> 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?),
> 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"
> Reserved for external use
> Coded slice
> 4, 5, 6
> 0xB 0x17
> 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.
More information about the Matroska-general