[matroska-general] Re: H.264 updates

Steve Lhomme steve.lhomme at free.fr
Fri Mar 14 09:55:42 CET 2003

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

> 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). 

That's simply impossible. Because that would mean a player should support the
normal Block and the BlockNALU that do exactly the same. We are not going to add
a new block system (and add backward incompatibility) everytime a new codec is
out :(

> 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

Ah OK, you want to put the lower priorities in another element...
Well then this idea is valuable, because it doesn't break backward
compatibility. The decision point is : do we need more than 1 bit left or not ?

> > 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.
> 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.

You mean adding 8 bits to the BlockNALU (compared to the normal Block) ? That
could be a good option if we separate them.

BTW, the name could be BlockPeel as it looks like the peeling system in ODD
Vorbis. That allows the container level (regardless of the codec used) to remove
informations to save space.

That makes me think that the hinter tool we'll have to make (to make perfect
size files for Mode 2 CDs) could make use of this feature too :)
> 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.

Well, this system is obviously for streaming and network congestion (it will be
a long time until it is implemented and really efficient). And if we can have
matroska work well in this area too (after all that's the first container to
support it ;) let's go for it. It has no cost and potential benefits.

> 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.

I think your BlockPeel system is much nicer than the use of 5 valuable bits (for
the future). Systems that won't care about priorities, will just forget this
information. And adding an octet to the Block and call it BlockPeel is not hard
and keep many bits left too.

More information about the Matroska-general mailing list