Re: 3ivx decoder and Haiku

> Axel D=C3=B6rfler  <[email protected]> wrote:
>=20
> > "David McPaul" <dmcpaul-bzGI/[email protected]> wrote:
> > > The main problem I had was that the new codec code seems to be=20
> > > expecting the avi fourcc to be swapped using B_SWAP_INT32 and=20
> > > this is=20
> > > different to the R5 media kit.
> >=20
> > If that's the case, the AVI extractor is likely to be the culprit.
> As far as I know, FOURCCs are defined to be stored in big endian.
> Thus, the fourcc "1234" must be stored as [1][2][3][4].
> However, it might have been a mistake to keep them inside the
> API as big endian.

Not necessarily a mistake, we just need to be consistent.

Although currently it does mean that I have to swap bytes when I=20
register and swap them again when I configure the 3ivx decoder.

> > > Seeking seems to not work correctly but I think that is currently=20
> > > an=20
> > > issue with the extractor not yet implementing seeking yet.
> Yes, the AVI reader doesn't do any seeking.
> I'll implement that when my Media Player replacement requires it.
> However, I just resumed work on the media kit, so it may take
> two or three weeks.

Ok.

> > > Since the 3ivx decoder handles many different MPEG-4 content it =20
> > > clashes=20
> > > with the avcodec and the codec's it registers for.  Are we=20
> > > looking at=20
> > > adding functionality to let the user choose the decoder using=20
> > > some sort=20
> > > of priority or niceness factor?
> Priority or niceness isn't a good idea.
>=20
> > IIRC that's the plan, although I don't exactly remember how it was=20
> > planned - we've changed plans at least once there :)
> We planed to allow the user to configure which codec is chosen for
> a particular format (from a list of codecs that support the format),
> but nobody implemented it.

Is that the intent of the codec_mapping file?

Cheers
David


--
Pretend to spank me -- I'm a pseudo-masochist!