Re: xvmc patch

Miguel Freitas wrote:
> 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
I thought xvmc means that the image is actually built inside the 
graphics card. So we will have no local image with which to do OSD 
compositing, so we will have to use xvmc compositing.
So, basically all the XvMC api calls, replace the old "transfer image to 
video card" call and also replace the current image buffer queue.

Cheers
James



-------------------------------------------------------
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