Re: xvmc patch

Hi Michael,

I added Mark Vojkovich to CC list, i hope he doesn't mind. Mark: we are
discussing adding XvMC support to xine. you can see the first thread
message at:

http://article.gmane.org/gmane.comp.video.xine.devel/5070


On Thu, 2003-08-14 at 07:36, Michael Roitzsch wrote:
> Generally a nice thing to have, but unfortunately, I don't know enough 
> about the why and how to make a thorough comment.

I don't fully understand it either, but this document should help us a
bit:

http://www.geocrawler.com/archives/3/1504/2001/9/0/6694888/

there must be a newer revision somewhere, but that should give us a good
idea.

>  Could you explain a 
> bit more in detail how it works? Especially: Is the communication 
> between decoder and video out necessary or could the XvMC-part be done 
> in a separate stage after the decoder?

afaict the communication is needed. the idea is to offload some decoder
work to hardware, therefore it must call XvMC for every frame to process
the macroblocks/motion vectors.

what i don't know though, is if the decoder depends on the result of the
macroblock rendering (XvMCSyncSurface + XvMCRenderSurface) to process
the next frame.

there is also the set_context call which is used for every new sequence
of pictures, creating new XvMC context and macroblocks structures. maybe
we could just create a new flag for get_frame (VO_NEW_CONTEXT?
VO_SEQUENCE_START?) and macroblocks would be returned within vo_frame_t?
looks cleaner: doesn't require a new vo_port/vo_driver method and still
communicates directly with the driver. 

> 
> I don't know, if these are possible, but here are my ideas on how I 
> would like to see this implemented:
> 
> * define a new frame format besides the current two YUV formats,
>   something like a XvMC-frame. This would not contain real image data,
>   but would be filled with a struct that contains all data necessary to
>   do the XvMC decoding

sounds good. these extra structs would be added to vo_frame_t. for
example: xine_macroblocks_t *macroblocks;

> * a new port capability announces, if the port can handle such frames

that's easy, VO_CAP_XVMC_IDCT.

> * decoders would query this capability to decide, whether to do complete
>   decoding into a YUV frame or partial decoding into a XvMC frame

ok

> * the conversion from an XvMC frame to a regular frame would be done
>   outside of the decoder, if it's possible (timing concerns) the
>   XvMC-capable video out could do it itself or some mechanism needs to
>   be introduced to do such a conversion before the video out loop
>   (of course this is another application for my idea of automatic frame
>   type conversion plugins, but until that is implemented, a post plugin
>   might do)

afaict video_out_xvmc checks if macroblock rendering is complete before
calling XvMCPutSurface. if not it does XvMCSyncSurface which will force
finishing rendering all macroblocks. this is post-video_out loop, so
there might be timming issues here.

i like your idea very much. however, if we want to have the frames ready
for being displayed at the time video_out say so, i have a felling we
can't escape of having proc_macro_block().

i believe this is similar case to img->copy. the decoder can call it
while decoding, but if it doesn't, video_out.c takes care of "copying"
the frame at the time it is being enqueued.

having a post plugin to do it doesn't help much imo. we still need
proc_macro_block() to be available at video port api.

thanks for your thoughts! :)

Miguel




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01