[gst-devel] [Fwd: GstIndex: some questions about usage]

[Wim Taymans]

On Tue, 2006-11-21 at 19:05 -0800, Erik Walthinsen wrote:
> Not sure why there's been a rash of people sending these questions directly 
> to me all of the sudden...  Maybe the lists need to be more prominently 
> placed in e.g. AUTHORS etc.
> 
> -------- Original Message --------
> Subject: GstIndex: some questions about usage
> From: Sebastian Dröge <slomo at circular-chaos.org>
> To: Erik Walthinsen <omega at temple-baptist.com>
> Date: Tue, 21 Nov 2006 17:06:31 +0100
> 
> Hi,
> I'm currently trying to understand GstIndex in all it's aspects and
> you're the original author judging from the header. I have some open
> questions that I couldn't answer myself from reading the code:
> 
> a) What exactly is a "group" meant to be? What would be example usages
> where someone would use different groups? I saw that you can give a
> group a certainty and a parent group with more certainty but these
> informations are never used in the implementations GstMemIndex and
> GstFileIndex and are in the private API part of the group. On the other
> hand there are functions to set/get the certainty of the index, how
> would this be useful?

The idea of the group is to incrementally construct the complete index.
An example would be an mp3 decoder: it starts reading the file and can
with great certainty store offset-timestamp pairs in the index. If a
seek happens, it does a best effort guess to a byte position based on
average bitrate or so. From there on it continues indexing again in a
new group, with less certaintly because the initial offset was a guess.
At some point in time after some seeking, the different groups will
start to overlap and the probability those overlapping groups increases.
At some point the groups can be merged until you have a complete index. 

> 
> b) What's exactly the usecase of different writer ids? What advantage
> could one have when using different writer ids instead of a single one
> for everything? Also why is there a gst_index_add_id() to add a writer
> id to the index when one should always get the writer id via
> gst_index_get_writer_id()?

The index is a mechanism for the application to get an idea of what's
going on in the media file while at the same time provide a way for
elements to keep track of offset-timestamp-foo tupples. It has never
fully been implemented or used but the ideas are still valid.

The application would construct a specific GstIndex from the available
indexers in the registry (or a custom one) and will then give this index
to all plugins in a pipeline. Each of the plugins then registers itself
in the index before starting to add entries to it. This allows for each
writer to store its own tupples without interfering with any other
writers. It also allows the writers to find their previously written
entries in an index. 

Consider a pipeline with an mpeg demuxer, an mpeg video decoder and an
mp3 decoder. The mpeg demuxer will want to store in the index the byte
offset, SCR,  PTS and type of PES packets so that it can perform an easy
seek on time later on. 
The video decoder might want to store the offsets and timestamps of the
frames along with a flag that the frame is a keyframe. The mp3 decoder
might also want to store offset-timestamp of the mp3 frames for faster
seek. 

Normally an application will index a file first by letting the file run
to EOS after setting the index on the pipeline. This is typically done
when importing a file in an application such as a video editor. The
index is then typically serialized to a file next to the unindexed file
(depending on the indexer). The application can then give this index
back to the (same) pipeline so that the elements can locate their
indexed entries again and optimize their seeking.
The application can also use the index to mark keyframes in the gui,
figure out good spots for cutting the file, etc..

The mechanisms for storing and getting the writers are therefore quite
flexible to allow for different pipelines to use the same index.

> 
> c) Is it correct that associations have to be added in chronological
> order? GstMemIndex prepends them to a list where one of the previous (or
> next) elements of the list is used when the parameters of the found
> entry are not the ones that is requested. If the list is ordered
> randomly the previous (or next) matching element could be something
> completely different to the one you want

I would say that this is up to the indexer implementation. 

> 
> d) What exactly is the use of entries with type GST_INDEX_ENTRY_OBJECT,
> i.e. gst_index_add_object()?

The ability to store arbitrary objects would be nice, like store the
caps of the different streams or metadata. 

Hope this helps
Wim

> 
> 
> That's it for now... I hope you find some time to answer my questions :)
> I plan to either convert all demuxers/muxers/parsers to GstIndex instead
> of home-grown implementations or or write a new class that better fits
> the requirements of all elements.
> 
> Bye
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________ gstreamer-devel mailing list gstreamer-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
-- 
Wim Taymans <wim at fluendo.com>