[matroska-general] Re: H.264 updates

Pamel Paul at msn.com
Fri Mar 14 04:52:36 CET 2003

"Steve Lhomme" <steve.lhomme at free.fr> wrote
> En réponse à Pamel <Paul at msn.com>:
> > 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
> it's such a good option.

I don't think I understand you.  I was saying to keep the Block as it is
now, and then have another element exactly like the Block, but with a an
8bit field for to identify the (either nal_unit_type or Category or
priority) and name it something like (BlockStreaming or BlockNALU).  Because
in every case for the next several years you will only use the Block how it
is now.  And the high priority units for H.264 could be stored in a regular
Block, but the low priority units could be stored in a (BlockStreaming or
BlockNALU), where the (either nal_unit_type or Category or priority) is
stored in the extra 8bit field.  If the 8bit field is stored within the
(BlockStreaming or BlockNALU), then how would you "have no way of knowing
which priority is associated to which Block"?

> 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

Maybe you should allow for a full byte of data in BlockNALU because the
specs have not yet been set in stone, and that is what they allow for.

Personally I'm not even convinced that it is even worthwhile to do this.
Matroska itself doesn't NEED to have all of the NALU's stored in seperate
blocks because you can store them all within one block.  That is the way it
was designed.  The only reason that we have heard to break down the NALU's
in Matroska, is to assist in streaming.  But none of us can even find that
this is true in the H.264 specs.

I think that before we go redesigning the core data structure of Matroska,
we should probably at least confirm that we have heard correctly.  What if
someone got ahold of charact3r, the Hdot264.sf.net project admin, and asked
him about it.  He would probably have the best idea of what NALU's are
really used for and what would be the best way to support them in Matroska.
I would hate to needlessly waste 5bits on every block in a Matroska file.



More information about the Matroska-general mailing list