FreeLists / openbeosmediakit / [openbeosmediakit] Re: 3ivx decoder and Haiku

["David McPaul" <dmcpaul@xxxxxxxxxxxxxx>]

> Axel Dörfler  <axeld@xxxxxxxxxxxxxxxx> wrote:
> 
> > "David McPaul" <dmcpaul@xxxxxxxxxxxxxx> wrote:
> > > The main problem I had was that the new codec code seems to be 
> > > expecting the avi fourcc to be swapped using B_SWAP_INT32 and 
> > > this is 
> > > different to the R5 media kit.
> > 
> > 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 
register and swap them again when I configure the 3ivx decoder.

> > > Seeking seems to not work correctly but I think that is currently 
> > > an 
> > > 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  
> > > clashes 
> > > with the avcodec and the codec's it registers for.  Are we 
> > > looking at 
> > > adding functionality to let the user choose the decoder using 
> > > some sort 
> > > of priority or niceness factor?
> Priority or niceness isn't a good idea.
> 
> > IIRC that's the plan, although I don't exactly remember how it was 
> > 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!