Re: to be effcient or not to be efficient

On Wed, Jan 07, 2004 at 12:54:44PM -0500, Toby Hudon wrote:

> > Could you please fix your mail client to break lines
> > at 65-75 characters ? Thanks.

/me joins the suggestion

> > That's right, it should not have more than a few entry points, but
> > also not more than a few message types. 
> >
> > I think there should be first some use cases written down as there
> > are only some vague ideas what can be done with such an API
> >
> 
> Ok, let's consider doing that then. Let's see, just off the top of my
> head:
> 
> get data, in sequence (playback) 
> get data, random access (seek)

i often need something in between - "get data, in weird sequence". e.g.
backwards or skipping frames in some regular way - for low latency
variable playback speed and direction and time-effects - when effects are
applied not to the content of frames but to their order, including
mixing frames from several sources in time.

not that i want a low level API imlement these sorts of access, but it
should allow me to wrap a demuxer in my code that implements the
specific sequence. 

> write data, in sequence not sure if we'd ever have a non-sequential
> write (encode)
> 
> capabilities reporting messages? Or do we just use try and if fail try
> something else? Note you could just set an internal flag on the first
> success to remember what to do on every subsequent call for the
> remainder of the video so you only have the mutliple call overhead
> once.

if i were to implement it i'd put capabilities in some datastructures
which are getting registered upon initialization. the main api [not
codecs] will provide some iteration through / searching in the central
registry. 

> variants on these for the various data types (frames, subtitles,
> audio)
> 
> We probably want init as a seperate API function, not a message.

i guess i have to reread the thread about messages for i don't really
understand why.

why cant init function for shared library return a pointer to a
vtable with pointers to implemented calls and NULLs for not implemented? 

> That's basicly all VFW has for codecs, it's got like 4 functions to
> just get the info about what's coming, find out if it can compress,
> and setup the codec. Then 99.99% of the calls go to the main compress
> or decompress function.
>  
> I'm probably forgetting some other important things but please help me
> out on it. --

this discussion starts to sound more like what i had in mind when
subscribed ;)

-- 
gr{oe|ee}t{en|ings}
artm