[openbeos] Re: Media kittens
- From: François Revol <revol@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 11 Jan 2002 22:22:34 +0100 (MET)
I have to disagree here.
First because the oal as stated is to be source and as of possible bin
compatible with BeOS. I understand this extends to this area too.
Second, because the current API has some lacks anyway (I'd not say it's
broken, it's not, only the addons are, even the AVI extractor from Be has
problems. Others addons have bugs I think only because even having the headers
and an NDA, that doesn't tell you everything you need to know).
That why the next version of NiftyPlayer, along with a complete rewrite, will
include a "NMediaKit", that I intend to donate to OBOS when it's ready (that's
not for tomorrow though). So what I think would be the best way:
1) for R1 try to stay on R5 tracks and mimic the media kit as far as possible.
2) for R2, extend the media kit with parts of other sources from Glass Elevator
and the NMediaKit. This also has the advantage of having nplay be a test field
for the NMedia Kit, so it can be more mature when it comes the time OBOS will
use it.
François.
En réponse à Isaac Yonemoto <ityonemo@xxxxxxxxxxxx>:
>
> Why don't we design a new API. We should also do 3, and provide a
> "quick
> wrapper" for the old binaries. A lot of the encoders/decoders are
> pretty
> bad anyway, and apparently, the Media kit was broken. This way we can
> not
> worry about making the Media kit *work* first, and a fluid design
> paradigm
> will work, too.
>
> just my 2c
>
> Isaac
>
> > 1) get these headers legally from Palm. I doubt that this is
> possible.
> > 2) design a new API from scratch. Will be much work.
> > 3) do a litte reverse engineering on the binary files that already use
> this API.
> >
> > I think 3 is the way to go.
> > By running
>
>
>
Other related posts:
