Re: to be effcient or not to be efficient

On Wed, Jan 07, 2004 at 08:37:25PM -0500, Toby Hudon wrote:
> > 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.
> > 
> 
> Ok, but wouldn't that fall under "random access?"

yep, it will. i just meant - remember that there's also this kind of use
when you implement it. 

seeks in a playback systems are implemented with "discontinuity" message
that passes the same way media buffers / frames would usually go and
resets some the modules [input/demuxer/decoder] parameters. this implies
that discontinuity event is something happening more rare then "normal"
("sequenced") access. 

if i do some time effects the discontinuity happens all the time.
discontinuity is an mpeg and similar formats influenced technique - when
seek happens in mpeg stream there's quite some stuff to do: you have to
seek to the requested place and then wait for the keyframe, or you may
chose to seek to the keyframe somewhat earlier then the requested place.

when i build interactive multimedia setups, i use frame based formats
like Motion JPEG [every frame is separate JPEG picture] or even PNG if i
need Alpha layer in material. but my favorite media engine still does
all these MPEG influenced tricks if i just wanna shuffle the frames or
play the stream backwards. 

hence my opinion is that media access API should provide simple way to
get any frame at any time. discontinuity handling may be added on top of
the API, although of course the means to implement it should be present
in the low level api [like indication if the frame is a keyframe and
some way to find out when are keyframes...] 

Also it should be possible to figure wether "get any frame" function is
expensive [i.e. wether the format is frame based]. then my applications
will ask VJ if he wants to convert(render) the film to some frame based
format [e.g. uncompressed] or chose other film to play. the "normal"
players may use this information to decide how to drop frames when they
must [e.g. if the JPEG frame has to be dropped it doesn't have to be
decoded, while MPEG frame that is not followed by keyframe must be
decoded]

> > why cant init function for shared library return a pointer to a
> > vtable with pointers to implemented calls and NULLs for not implemented? 
> > 
> 
> What's a vtable and what's an implemented call, and how do you have a pointer to it?

vtable ("virtual methods table") is a structure with pointers to
functions. the term is from OOP but the concept can be used in plain C
as well.

the codec implementer will have to do the following [pseudoC follows,
the functions are just examples]:

/***************************************************/
static frame_t get_next_frame(codec_t codec)
{
  ...
}
static void seek_ms(codec_t codec,int ms)
{
  ...
}

..

static vtable_t my_vtable {
  .get_next_frame = get_next_frame; /* implemented call */
  .seek_ms = seek_ms;               /* another one */
  .seek_frame = NULL; /* not implemented call */
  ...
}

vtable_t init()
{
  return my_vtable;
}
/***************************************************/

the main body of the library may implement safe wrappers to call the
vtables as well as some common api, e.g.
seek_to_nearest_keyframe(codec,ms);

actually codec api should be something like
decode(encoded_frame,raw_frame);
encode(raw_frame,ecoded_frame);

while the main body will implement streams incorporating input, demuxer
and decoder while remaining flexible enough for freaks like me wishing
to alternate the way the stream components interact.



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