[Matroska-devel] Re: RFC 1134 - New EBML Block design

Paul Bryson paul at msn.com
Sun Jan 25 19:34:49 CET 2004


"Moritz Bunkus" wrote...
> If we be radical we can also think about using simple flags for track
> types. We could use the bits 3 and 4 like this:
>
> 00: I frame
> 01: P frame
> 10: B frame
> 11: invalid

I think Steve's original system was a little more intuitive.  (Not available for
viewing because of a CVS failure.)

00: No frames referenced. (I frame)
10: Frame with previous timecode referenced. (P frame)
01: Frame with following timecode referenced
11: Both previous and following timecodes referenced. (B frame)

> The ReferenceBlocks would then be _optional_ for such a block. If
> they're not present the references are implicitely given. However, if
> some special application needs some special references it may still add
> them. The number / types of references must then comply to the flags
> used.

Why prevent either/or situations?  For instance, you could have a block that
references the previous and following frames, plus another frame two previous.
If using the flags, then you wouldn't have to write two of the timecodes, just
the one not covered by the flags.  But, some application might want to make
special use of these and allowing them to use both the flags and the reference
blocks shouldn't be a bad thing.

> This would save us a lot of space.

As stated, 3 bytes for every P frame and 6 for every B frame (while using 1ms
accurate timecodes). For real world savings, we could use some very conservative
settings from the XviD Matrix trailer. 3635 frames, of which 299 are Key frames,
with at least 30% of the remaining being B frames and rest as P frames.But about
8% as keyframes, and this is for a high action trailer so the numbers will be
very conservative compared to real life. But using these numbers, using a 2 hour
movie at 24fps would yield 172,800 frames. So:

333,849 bytes for P frame references
286,156 bytes for B frame references
620,005 Total bytes for frame references

If you allowed more than 1 consecutive B frame, you would get much higher B
frame numbers and could exceed 1MB of overhead.  This is of course fixed
overhead that has nothing to do with the bitrate of the video.

This also offers possibilities for using references with audio frames.  MP3 can
require the Block before it to decode the current content correctly, and it
would be nice to know when that is the case without actually having to decode
the Block.  But, the current referencing system has to much overhead to do this
efficiently.


Pamel








More information about the Matroska-devel mailing list