[MPlayer-dev-eng] New Codec Interface

[Juan J. Sierralta P.]

On Tue, 2002-02-26 at 14:21, Mike Melanson wrote:
> Hi team,
> 	A'rpi, I checked out your first draft of the new codec interface.
> Good thinking, overall. So, if I understand it right, the demuxer will not
> make any decision regarding the dimensions of the video in a file, and the
> output format will no longer be specified in etc/codecs.conf? Instead, the
> decoder will callback to the MPlayer app and specify a list of formats
> that it knows how to output? And it will also make the decision about the
> image dimensions? Or will the file demuxer get the dimensions from a file 
> (if available), and give the decoder veto power over the dimensions?

	IMHO that's the way to do it, just the decoder knows (after decoding
first header) image dimensions and probably PTS, PAR, fps and color
space. BUT there are some formats like VIVO or QT that put the image
dimentions (diferent of course) in the stream, this is mostly to avoid
limitations on some codecs like H.263v1 which don't support arbitrary
dimensions.
	OTH the idea of the formats negotation and direct rendering on
framebuffer memory are nice and most modern multimedia API do that, I
haven't work with DirectX/DirectShow stuff but BeOS as the same idea
including timestamps for real time rendering.
	About Direct Rendering on libavcodec this could be done but with a
generic framework not only for MPlayer DR.

> 	Another thing that wasn't quite clear: Will this new architecture
> entail having the decoders dispatch video frames to the video rendering
> subsystem (like in VFW and QT, as I understand them)? Or will it be like
> the current system where MPlayer calls a decoder, the decoder draws the
> frame to a buffer, and returns execution to the main app and lets it worry
> about drawing the frame?
> 
> 	Also, is it okay if I monkey with the sh_video_t structure and add
> a proper palette structure?

-- 
Juanjo sin .sig :(