Re: to be effcient or not to be efficient

On Thu, Jan 08, 2004 at 11:22:30AM +0100, Ronald Bultje wrote:
> On Thu, 2004-01-08 at 09:57, Artem Baguinski wrote:
> > 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 */
> >   ...
> > }
> [..]
> > 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.
> 
> I really don't see how this is any different from what ffmpeg, GStreamer
> and mplayer are currently doing?

i'd like the result of this discussion to be "let's accept XXX as a
foundation of our api because it has what we need and doesn't have much
'extras'. let's just add what we miss."

the problem with saying that in the beginning of the discussion is that
it'll sound to radically-conservative. i prefer to gradually create an
abstract model that looks close enough to XXX and then make the
suggetion.

> Let me state it differently: you're recreating existing stuff. Without
> adding anything new to it. That's not a good idea.

let's call our hypotetical product YYY. 

you're saying 
  
  YYY = ffmpeg
  YYY = mplayer
  YYY = GStreamer

that means: ffmpeg = mplayer = GStreamer

which is definitelly not the case. but there is a large overlap between
the three. i'd like the mysterious XXX to be this overlap. 

because i have to create software which is not exactly ffmpeg, not
exactly mplayer, not exactly gstreamer, but still requires part of their
common functionality - simple access to video and audio.

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