[gst-devel] Scrapping the GstIndex

[LRN]

The idea goes like this...

Each element that alters the index in any way, such as
a) split a stream into a few substreams or merge a few substreams into
one stream (all muxers/demuxers, all mixers)
b) alter a stream - add a delay, trim the length of a stream (gnonlin et
co.)

has to adjust all seek events that go through it. Whether it will use an
index table, a math expression or something else is no-one's business.
Other elements won't know what and how the conversion is made. Of
course, that element will have to alter newsegment events too (assuming
that each seek event generates a newsegment event), since the segment
that came from upstream (talking about push-pipelines here) would be
invalid downstream.

AFAIK, this is being done in some elements at the moment, it just has to
be implemented in each element where it is applicable.

When seeking fails and event-pushing function returns FALSE, and element
could try to convert the seek event to a format that could be understood
by upstream element and push it again (querying seek capabilities before
doing that).

About synchronization. I see 2 possibilities:

1) Seek event chain affects only one stream.
If that stream is a result of combining a few streams, all these streams
are affected.
If that stream is a result of splitting a stream, that stream is
affected independently (i.e. we would be able to seek a video stream
without seeking the audio streams that go along). Synchronisation is
performed by the pipeline (it should generate a separate seek event for
each sink to keep all streams in sync).
Since application can seek not the pipeline, but an arbitrary element,
this way doesn't seem right.

2) All seek events are tagged with an unique seek ID.
When an element gets a seek event on a source pad, it queries its other
source pads (in case it's some kind of a demuxer) to convert the marks
it got from the event to the marks applicable for these streams (this is
needed to properly adjust newsegment event that will come from upstream
after successful seek), then converts the event and forwards it
upstream. So, if you seek an audiosink, its audiostream will be the
base, and seek intervals for other streams will be derived from that
base (as precise as possible).
When an element has more than one sink pad (mixer) and gets a seek event
from downstream, it sends a separate seek event via each sink pad,
assuming that each pad leads to a different source. If they lead to the
same source, the source will either get two identical seek events with
the same seek ID (it follows the first one and ignores the second one,
since it remembers ID and params of the last valid seek event it got),
or will get two different seek events with the same seek ID (in which
case it either breaks the synchronization between the streams and seeks
them separately, or will refuse to seek, claiming that it can't read the
stream in two places simultaneously).

Speaking about frame-based seeking (my favourite subject!), it means
that a decoder will get a seek event, look up the frame in its index
table (it has to get one!), find appropriate keyframe, remember
everything it needs (in case it gets some query back from upstream),
convert the event (change it from the frame requested by downstream to
the keyframe) and forward it upstream. Upstream demuxer will just seek
where it has been told, it shouldn't know anything about keyframes
(since demuxer may or may know something about keyframes, while decoder
is THE element that knows everything about them). Synchronization is
implicit (demuxer will assume that audio/video/subtitle streams come
from upstream filesrc in sync and will query downstream elements just to
come up with a valid new segment boundaries for these streams).

Another example - audio tracks on a CD (i've seen something about that
in cdda). Application will have to seek the cdda element to perform a
track-based seek, because other elements (such as audiosinks) wouldn't
know anything about tracks. Well, maybe the pipeline (a bin) will know
how to forward a track-based seek request to cdda (probably because it
knows each element's seek caps).

GstIndex doesn't fit in here. At all. Hence the subj.