[matroska-devel] Re: [UCI-Devel] Project status

Steve Lhomme steve.lhomme at free.fr
Wed Feb 5 16:36:36 CET 2003

En réponse à alex at foogod.com:

> > You replace these numbers with timecodes, and you have exactly what I
> p=
> ropose
> > (and what is used in matroska).

(your mutt agent does really funky cuts ;)
> Umm, no, you don't.  Your timecodes provide no forward-looking
> informatio=
> n,
> which this method does.  You also need to have far more complexity to
> rep=
> resent
> multiple dependencies.

So you think that a frame with timecode 100 and a reference to timecode 20 and
one to timecode 150 doesn't give the direction to look for (backward/forward) ?

Why did I chose the timecode instead of a count reference ? Because if you lose
a frame in between your counter is fucked and all P or B frames are lost. While
with the timecode only the missing frame is lost (unless the missing one is an I

> > for the memory you mention. The memory dependency (1 or 2 frames

> Umm, no, you miss the point.  The question is where _are_ the 2 (or
> whate=
> ver)
> frames that need to be buffered.  Say you have a typical MPEG sequence

I was talking _only_ about the memory requirements. An unbounded system (like in
matroska) allows very complicated things to be done. But in the other hand you
usually need to know if you're going to be able to read a file or not. This can
be done with a flexible system with a note on the limitation or analysing all
references before playing to check wether it will be possible or not to read the
file (this can be done by checking the cue/seek entries).

*Where* is the data is handled in MCf/matroska by :
- cue/seek entries checking
- know the position of a past frame
- seek frames in the file until you find the one you need.

I see one limitation, you already mentioned, to these methods. If the forward
(future) frame is far ahead, you have to cache all the data in between if the
transport layer doesn't allow seeking back. That could lead to unlimited memory
use. In a real-world example, the memory necessary would be the same as for the
encoder (which have the same frame in memory when generating the references) (at
least when you deal with real time encoding).

I see 2 solutions to this problem :
- fix some maximum buffering on a track (like "the encoder is allowed to cache
2MB of frames before outputing the data")
- store the frames in encoding order :D which would be a radical change for
matroska and MCF, in the philosophies and the possibilities.

That would be possible to use encoding order in matroska... Keeping the
(timecode) references as they are. That means you would be able to have a frame
"in the past" after every frame (considering the frames already read), as long
as it references known frames.

The problem is to know when a frame is never referenced again in the stream (a
flexible system should allow overlapping of references). I can't think of any
good system for the moment... The 

More information about the Matroska-devel mailing list