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

[ensonic]

hi,

maybe I should outline my interest into the index stuff. Current demuxers
build an index table in memory when parsing the container. That is usually
a list of structs, where each struct is one index enry. the index entry
contains stuff like byte-position, timestamp and flags. For the avidemuxer
thsi struct is 44 bytes. For long clips this could lead to quite some
memory usage (several mb).

I understood the pluggable indexer concept as a way to have different
storage backends. The 'normal' indexer would keep a list (or tree) of index
entries. Then we could have a 'low-mem' indexer, that would rather
recalculate things that caching them and that could also merge index
entries to keep the total index size below some minimum. For the latter I
have some code that uses lots of #ifdefs in avidemux, which is quite a pita.

Stefan

On 4:05:47 am 22/11/2006 Erik Walthinsen <omega at temple-baptist.com> 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?
>
> 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()?
>
> 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
>
> d) What exactly is the use of entries with type GST_INDEX_ENTRY_OBJECT
> ,
> i.e. gst_index_add_object()?
>
>
> 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