Re: [Openquicktime-devel] Messed CVS + Feature Request

[Alexander L. <ale...@ve...>]

Hi Jozef!


> Von: "Jozef Hatala" <jh...@ho...>
> Datum: Fri, 12 Jul 2002 06:25:34 +0200
> An: ya...@3i..., ope...@li...,
> ale...@ve...
> Betreff: Re: [Openquicktime-devel] Messed CVS + Feature Request
>=20
>> We could implement something like "merits" in Directshow Filters : each
>> codec would register itself whith a dword merit. When encoutering a know=
n
>>  fourcc, the OQT lib would try codecs in order of merit. All the codec
>> given
>> with the OQT lib could have a NORMAL merit, then user wanting to overloa=
d
>> codecs could just register their own codecs with a higher merit ... simp=
le
>> and efficient ;)
>=20
> At registration time, if there is a codec with the same signature there,
> either
> we replace it, or we don't honor the new registration, based on merits.
>=20
> Detail: Low merit codecs should never be in a plugin with their signature=
 in
> the
> file-name, so that all plugins have to be opened, otherwise the "better"
> implementation
> has no chance to show its prooves.  Luckily enoght it's the case for the
> "simple" codecs
> and for decoding-only aliases (like DIV3 and DIV4 in DX50).
>=20
> I was thinking about this. Then I realized that it would be great to have
> different
> merits for the encoder and for the decoder (example: 3ivx decodes DIV4, b=
ut
> you
> would have to use the original codec for DIV4-encoding).
>=20
> But this seems to be difficult to do the way things are now, mainly becau=
se
> when
> a codec is loaded we can't know if it is for reading or for writing.  And
> you can imagine an application that uncompresses a file, transcodes a tra=
ck
> and recompresses it. The codec will be loaded only once.
>=20
> That's why I gave up :-(.
>=20
> But having merits at the plugin level seems interesting though.  I'll try=
 to
> do it.
>

=20
Sounds great.

>>> I agree that deregistering could be good but in this specific case
>>> why do you want new (better?) versions of RLE and RAW ? - why not
>>> just replace the exisiting code - which I'm not sure even works yet
>>> (Jozef?).
>=20
> raw  video (RGB and RGB+alpha) works, as far as I know.  RLE is independe=
nt,
> it can be added without modifying the rest.
>=20

You're right. RGB8 and RGBA8888 do work. Somehow I would opt for a slightly
faster approach, like in qt4linux. It checks if the output rows are
consecutive and then instead of row by row memcpy you can do it with one.
I am not quite sure if this is much faster.
Also, one (who volunteers?) could implement SSE or MMX or whatever memcpy
routines as in mplayer.

I also added an RGBA8888 raw decoder, because sometimes we need this for
compatibility reasons. But I realized that the colormodels stuff from
qt4linux is now in OQT. And now I realized that it is possible to decode
into a different format than supported by the codec! Thanks. Bt as far as I
know this has not been possible until some weeks ago?!

So I added an RLE decoder for RGB888, BGR888, RGBA8888, ARGB8888 based on
the one in Xanim. I think I could send you the code and somebody puts it in
the CVS (if it meets your coding requirements :-)


=20
> If there is something wrong with video codecs, please complain, I care ab=
out
> it.
>=20
...
>=20
> Jozef
>=20
> _________________________________________________________________
> Join the world=B9s largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>=20

Cheers,

Alex

--=20
Alexander.Lechner     @        vertigo-systems.de
Beethovenstra=DFe 5-13  |    phone: +49-221-2405472
D-50674 K=F6ln          |      fax: +49-221-2722510