[xine-devel] BUF_FLAG_PALETTE

[Mike M. <mel...@pc...>]

Hi team,
	It is time to bump up the demuxer API version number again. I want
to add palette support to xine. This is something I have been wanting to 
do for awhile but I was waiting until I knew enough about the demuxers and
decoders to pull it off.

	Necessity: Some multimedia files store RGB color palettes that the
video decoder needs in order to render the image. It would be nice to have
a standard, demuxer- and decoder-independent, method of transporting the
palette data from the demuxer to the decoder. AVI, ASF, and MOV will use
this facility, for starters.

	Proposol: Increment the demuxer API version number to support a
new flag named BUF_FLAG_PALETTE. No other flags would be set in a packet
that sets this flag. Packet member decoder_info[1] will contain the number
of RGB palette entries. Packet member decoder_info[2] will contain a
pointer to an array of RGB structures. The number of structures in this
array will, of course, be equal to decoder_info[1].

	On the demuxer side: Demuxer sees that it must load a palette.
Allocate enough RGB structures for each entry, create a packet with the
BUF_FLAG_PALETTE and send the palette to the decoder. Note that the packet
has no other data.

	On the decoder side: Video decoder checks for BUF_FLAG_PALETTE. If
it finds it, copy the palette info from the decoder_info fields. The plan
is to not require an API version increment here. The packet will be empty
so data will not be accumulated in the decoder's buffer. And the
BUF_FLAG_FRAME_END flag or any other flag is not set, so this will not
inadvertantly trigger any other operations in the typical video decoder.
The upshot here is that we do not have to revise all of the video
decoders, just the ones that care about the palette (this includes Ewald's
MSVC decoder right now).

	Any holes in this plan? The only loose end I can see is, where
does the palette structure that was sent to the decoder get free()'d?
Should the demuxer be responsible for keeping a copy of the address around
and freeing it during its _close() operation? Or should the video decoder
worry about it?

	If I do not receive any response on this, I will assume it is okay
and implement it in the next week or 2...:)

	Thanks...
--
	-Mike Melanson