Re: to be effcient or not to be efficient

On Thu, Jan 08, 2004 at 12:34:49PM +0100, Ronald Bultje wrote:
> On Thu, 2004-01-08 at 12:09, Artem Baguinski wrote:
> > 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.
> 
> The problem with creating a new product from the ground up is that it
> takes time, developers, etc.

misunderstanding: i'm not talking about creating new product. i'm
talking about creation of ABSTRACT MODEL in the minds of other
subscribers in this list that looks similar to ffmpeg or its part. and
after i see that we all understand each other i'll "make my suggestion"
[which you have stripped from the answer, but it was something like "why
not make XXX [ffmpeg] a foundation for our project"]

> > you're saying 
> >   
> >   YYY = ffmpeg
> >   YYY = mplayer
> >   YYY = GStreamer
> > 
> > that means: ffmpeg = mplayer = GStreamer
> 
> No, I'm saying that all the discussion I've read so far are all about
> issues that each of the three above have already solved. They're not the
> same, but they each solve the issue. That's different.
>
> > 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.
> 
> Why do you need a new product for that? Why not adapt one of the
> existing ones and make it better than it is right now (missing
> functionality could be considered a bug on itself)?
> 
> Differently: what's wrong with ffmpeg that makes it unusable and/or
> unadaptable for the product that you guys are after? Same question for
> mplayer & GStreamer.

there's nothing wrong with any of them.

but mplayer is a media player which is optimized to playback media in a
specific way. my requirements are: being able to quickly create simple
applications that implement different playback models [dependiong on an
art project i'm working on]. i need uniform api to access various video
and audio sources but i want to be free to decide what i'll do with them
and how i will do that. 

the last time i looked into sources of the mplayer it was quite
difficult to modify it to my needs quickly. the problem is i usually get
about 2 months to implement a new project and simplest solutions are the
only way to do that. so i use libraries like quicktime4linux or avifile
or dc1394 etc depending on what the current project needs. 

the only problem with that model is that each media source has its own
api while what i want to do [read / receive / write / send frames and
samples] is mostly the same. it's quite inconvenient and although i
implement the projects according to specifications, i personally am not
satisfied with limited features of the applications i deliver.

ffmpeg and GStreamer are closer to what i need. GStreamer is a bit
higher level and has features and functionality which i usually don't
need [if/when i'll need them i'll probably use GStreamer]. 

> What you guys are after is unification, but you're creating a new
> product that will make the distortion only worse. Sounds illogical to
> me.

just a misunderstanding. i'm for merging the efforts and will be happy
to redirect everybody here to fixing and extending ffmpeg to our various
needs. that was my [secret] mission when i joined this mailing list. i
just have chosen different strategy to achieve this goal then direct
critisizing of everybody else [although that method is just as valid].

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