[Matroska-devel] Element order in EBML/libebml
suiryc at yahoo.com
Mon Oct 20 17:24:29 CEST 2003
--- Ronald Bultje <rbultje at ronald.bitfreak.net> wrote:
> On Mon, 2003-10-20 at 16:56, Cyrius wrote:
> > If order doesn't matter that means you would have
> > load the file in memory and sort the elements to
> > back the correct order (that's just to point out
> > nonsense behind "order doesn't matter")
> That's what DirectShow and GStreamer do, right? At
> least GStreamer does
> so in a way. We read blocks from files, place them
> in a queue and let
> the decoder decode it when it feels like it. Then,
> the outputs play this
> decoded data back (possible from another queue).
> There can be any number
> of queues in the pipeline and any number of buffers
> (with a maximum, of
> course, but that's not the point). The only element
> that takes care of
> sync is the video/audio output. So I might be
> reading 10 MB ahead of the
> data that I'm currently playing, my decoder might be
> 8 MB ahead and the
> rest might be queued in between. So if my
> video/audio data of the same
> time are 8 MB apart from each other, you won't
> notice (in GStreamer).
> Order indeed doesn't matter, not that much.
> Placing things in order still can matter at parts
> where the queue'ing is
> harder than this. Imagine live stream viewing, these
> kind of things.
> That's why you try to keep streams synchronized in
> the file.
It's true that the data can be buffered (when
possible, it's harder in live streaming as you said)
in case the data interleaving is shifted (that's e.g.
the case in AVI when using preloading of audio).
The problem here is that the specs don't say you can't
(e.g) swap the order of the data (i.e. write frame 5,
4, 3, 2, 1 in the file).
When you know what kind of stream it is you can still
reorder the frames (for a standard I/P stream the
frame order should be 1, 2, 3, 4, 5; for I/P/B streams
in coding order it would be ...; etc), but if you
don't know in which order send the frames to the codec
there will be problems (if you send frames in reverse
order the codec will think that the stream is broken
and won't decode properly the stream, and will
certainly not sort the frames for us, nor the
multimedia layer used - DirectShow, GStreamer, ...).
--- Steve Lhomme <steve.lhomme at free.fr> wrote:
> OK, I agree, there IS a problem based on what I said
> with the MPEG4
> encoding order (as an example). I proposed that we
> add an order number
> to each block (or to each frame) that would help
> such a possible
> reorder. But for now this is not a problem and
> probably never will.
> Because I don't know any reader that change the
> order of elements on
> reading. And rewriting or adding elements to such an
> element would not
> change the order in libebml (and probably any other
Yes we all write the data in the correct order because
for us the order matter for the data.
It's true that for some elements in the file the order
doesn't really matter (e.g. KaxChapters could be
before KaxTracks, after KaxTracks and before the first
KaxCluster, or even at the end of the file; of course
in this case the KaxSeekHead would help to know where
the element is if we need it right at the start), but
in the case of the data (KaxBlock) the order matter if
you want to be able to decode the stream. So IMO
"order doesn't matter" ... for some elements and
matters for others.
More information about the Matroska-devel