[MPlayer-dev-eng] Common Video and Audio API

[Mike Melanson]

Hi team,
	A'rpi: I just read your updated TODO list. I have some things I
could add to it, but I won't since I maintain my own *private* MPlayer
TODO list...:)

	I did notice your wishlist item to conceive a standard native
codec architecture. Do you realize that doing so will obsolete about
half of my lengthy codec-devel.txt document?...:) I certainly don't mind.

	I just wanted to start tossing out some ideas on how this might be
possible, based on my limited experience in writing decoders.

	Are you thinking of putting each codec in its own module and
installing it on a system, or compiling them all into a static library at
compile time to be linked into the main app during the final
link (like in libmpdemux)? Personally, I prefer the latter (it's just
easier to manage one big application).

	 I think that VFW (and ACM) provides a reasonable model for
communicating with codec modules. I think we can do without one single
entry point into a codec (e.g.. DriverProc). On the video decoder side,
each codec could be required to advertise _init(), _decode_frame(), and
_cleanup() functions. Each function could have a single parameter, a video
decode information super structure. the structure would have width,
height, and expected output format type, for starters. The
_init() function would expect to see the width, height, and image format
in the structure and call out to a standard MPlayer function (is there
one?) to allocate the decode frame (maybe 2) and store them in the
structure.

	Another necessary (occasionally) member for the structure is the
palette map in a standard format (BGRA or RGBA, I don't care as long as
it's standard). The _decode_frame() function will expect to see a pointer
to an encoded frame in the structure, as well as the size of
the encoded data. Naturally, the structure should also have a void * for
the decoder's internal use.

	The decoder's _cleanup() function will simply free all the
pointers used by the decode info structure.

	On the audio decode side, things will be pretty similar. The audio
decode info structure should have info such as sample size, endian-ness,
sample rate, and channels. The _init() function should allocate a decode
buffer. The _decode_frame() function will decode a chunk of audio pointed
to by a pointer in the structure. Rather than returning the number of
samples decoded, the number may as well be stored in another variable in
the structure. The _cleanup() function frees all the memory in the info
structure, of course.

	This has been a brief brainstorm. Feel free to expound upon, or
ridicule, my ideas, or toss out your own.

	Thanks...
-- 
	-Mike Melanson