> 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 . > 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!