[MPlayer-dev-eng] Extended support for xvmc

[Ivan Kalvachev]

Here comes collection of files and patches
that if applied correctly could allow you to test XvMC support for mplayer.
There are still many issues with it, so it is not compleate and bugfree.
I have placed the patches and files according to the files they change
The only exeption is xvmc_render.h that is used on few places.

Know issues:
 vo_xvmc is made as basic as possible. This meens that there is only X code
to make one windows and map it on the xvmc port.
 There is no check event NO KEYBOARD, NO MOUSE, NO RESIZE, NO FULLSCREEN,
NO OSD but they all WILL be added LATER ( I will be happy if some stuff
from vo_xv is moved to x11_common :)
 There are bugs in ffmpeg12 with software render, some blocks are decoder
wrongly, some are not drawn (i have send DMV patch, next todo is 16x8).
 Some streams that are rendered corretly by -vc ffmpeg12 but show artifacts
when decoded with xvmc, this bugs are still to be fixed, any help is welcome.
 When playing file add -noframedrop command line option, as i haven't
worked out frame droping outside vd_ffmpeg


So how it works:
  XvMC for render you need both image data and macroblock motion data.
  XvMC uses Surfaces to render frames. For each surface i allocate
xvmc_render_state_t ( find better name , at least state is not correct)
that hold information how to render surface (picture structure, 1'st/2'd
field etc..) and some additional information.

vd_ffmpeg - initiazlises itself with codec ffmpeg12mc, i have added such
decoder to libavcodecs. It adds custom mc_get/release_buffer and
mc_draw_slice.

vd_ffmpeg - request frame, i use DR1 to call vo_xvmc and take frame from
there

vo_xvmc::get_buffer fills mpi, and gives pointer to xvmc_render_state of
one of the free surfaces.

vd_ffmpeg::get_buffer - takes frame and sets xvmc Surface as busy for
prediction (it will be freed by release_buffer, so this surface could not
be used again)

libavcodec:mpeg12xvmc, renders slice, using replacement of MPV_decode_mb,
and then slice is compleate it call xvmc_draw_hotiz_band that calls out

vd_ffmpeg::draw_horiz_line - that using draw_slice reaches

vo_xvmc::draw_slice - it calls XvMCRenderSurface, and maks surface as
durty (pending for display) it will be cleared after the surface is show 
(hidden) or after frame is skipped.

libavcodec: when frame is done ffmpeg may or may not output it. it could
delay output to keep display order. Yes we do out of order rendering, as
this is the only way posible to do XvMC without skip all B frames.
if we display the frame then:

vd_ffmpeg: returns from decode, it check is image skipped.
then it pass mpi to the vo system

vo_xvmc::draw_image (!!not draw_frame!!) takes the mpi, it is marked as
DR1 and Callback supported, so we just store the mpi->render-> for
displaying.

vo_xvmc::flip_page is called at some time after draw_image, it marks the
current displaying surface as not durty (but it still may be locked for
prediction) and shows the new.

at some point libavcodec will call
vd_ffmpeg:mc_release_buffer - it will mark the surface as not requested
for prediction

this repeats in loop.

Well this letter became much longer that i intended to do.

Happy hacking.
 Ivan Kalvachev - iive

p.s. I wrote this by memory, i may have miswrite some things, read the
source.

Ivan Kalvachev said:
> Here is a patch that i want to commit now!
> it adds xvmc detection into configure (default is no)
> (i used xv detection as example)
> and adds 2 new image formats for future processing on xvmc data
> The interesting stuff will be posted here for approval and
> proposions after i do these changes
>
> Best Regards
> Ivan Kalvachev
>
> p.s. i resend the letter as i had some connection problems


-------------- next part --------------
A non-text attachment was scrubbed...
Name: XVMC.TAR.bz2
Type: application/octet-stream
Size: 17183 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20030621/c1680105/attachment.obj>